Message ID | 20240308223702.1350851-7-seanjc@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] KVM: x86: Selftests changes for 6.9 | expand |
On 3/8/24 23:36, Sean Christopherson wrote: > Add SEV(-ES) smoke tests, and start building out infrastructure to utilize the > "core" selftests harness and TAP. In addition to provide TAP output, using the > infrastructure reduces boilerplate code and allows running all testscases in a > test, even if a previous testcase fails (compared with today, where a testcase > failure is terminal for the entire test). > > As noted in the PMU pull request, the "Use TAP interface" changes have a few > conflicts. 3 of 4 are relatively straightforward, but the one in > userspace_msr_exit_test.c's test_msr_filter_allow() is a pain. At least, I > thought so as I botched it at least twice. (LOL, make that three times, as I > just botched my test merge resolution). > > The code should end up looking like this: > > --- > KVM_ONE_VCPU_TEST_SUITE(user_msr); > > KVM_ONE_VCPU_TEST(user_msr, msr_filter_allow, guest_code_filter_allow) > { > struct kvm_vm *vm = vcpu->vm; > uint64_t cmd; > int rc; > > sync_global_to_guest(vm, fep_available); > > rc = kvm_check_cap(KVM_CAP_X86_USER_SPACE_MSR); > --- > > The resolutions I've been using can be found in kvm-x86/next. > > > The following changes since commit db7d6fbc10447090bab8691a907a7c383ec66f58: > > KVM: remove unnecessary #ifdef (2024-02-08 08:41:06 -0500) > > are available in the Git repository at: > > https://github.com/kvm-x86/linux.git tags/kvm-x86-selftests-6.9 > > for you to fetch changes up to e9da6f08edb0bd4c621165496778d77a222e1174: > > KVM: selftests: Explicitly close guest_memfd files in some gmem tests (2024-03-05 13:31:20 -0800) > > ---------------------------------------------------------------- > KVM selftests changes for 6.9: > > - Add macros to reduce the amount of boilerplate code needed to write "simple" > selftests, and to utilize selftest TAP infrastructure, which is especially > beneficial for KVM selftests with multiple testcases. > > - Add basic smoke tests for SEV and SEV-ES, along with a pile of library > support for handling private/encrypted/protected memory. > > - Fix benign bugs where tests neglect to close() guest_memfd files. > > ---------------------------------------------------------------- Pulled, thanks. Paolo > Ackerley Tng (1): > KVM: selftests: Add a macro to iterate over a sparsebit range > > Dongli Zhang (1): > KVM: selftests: Explicitly close guest_memfd files in some gmem tests > > Michael Roth (2): > KVM: selftests: Make sparsebit structs const where appropriate > KVM: selftests: Add support for protected vm_vaddr_* allocations > > Peter Gonda (5): > KVM: selftests: Add support for allocating/managing protected guest memory > KVM: selftests: Explicitly ucall pool from shared memory > KVM: selftests: Allow tagging protected memory in guest page tables > KVM: selftests: Add library for creating and interacting with SEV guests > KVM: selftests: Add a basic SEV smoke test > > Sean Christopherson (4): > KVM: selftests: Move setting a vCPU's entry point to a dedicated API > KVM: selftests: Extend VM creation's @shape to allow control of VM subtype > KVM: selftests: Use the SEV library APIs in the intra-host migration test > KVM: selftests: Add a basic SEV-ES smoke test > > Thomas Huth (7): > KVM: selftests: x86: sync_regs_test: Use vcpu_run() where appropriate > KVM: selftests: x86: sync_regs_test: Get regs structure before modifying it > KVM: selftests: Add a macro to define a test with one vcpu > KVM: selftests: x86: Use TAP interface in the sync_regs test > KVM: selftests: x86: Use TAP interface in the fix_hypercall test > KVM: selftests: x86: Use TAP interface in the vmx_pmu_caps test > KVM: selftests: x86: Use TAP interface in the userspace_msr_exit test > > tools/testing/selftests/kvm/Makefile | 2 + > tools/testing/selftests/kvm/guest_memfd_test.c | 3 + > .../selftests/kvm/include/aarch64/kvm_util_arch.h | 7 ++ > .../selftests/kvm/include/kvm_test_harness.h | 36 ++++++ > .../testing/selftests/kvm/include/kvm_util_base.h | 61 +++++++++-- > .../selftests/kvm/include/riscv/kvm_util_arch.h | 7 ++ > .../selftests/kvm/include/s390x/kvm_util_arch.h | 7 ++ > tools/testing/selftests/kvm/include/sparsebit.h | 56 +++++++--- > .../selftests/kvm/include/x86_64/kvm_util_arch.h | 23 ++++ > .../selftests/kvm/include/x86_64/processor.h | 8 ++ > tools/testing/selftests/kvm/include/x86_64/sev.h | 107 ++++++++++++++++++ > .../testing/selftests/kvm/lib/aarch64/processor.c | 24 +++- > tools/testing/selftests/kvm/lib/kvm_util.c | 67 ++++++++++-- > tools/testing/selftests/kvm/lib/riscv/processor.c | 9 +- > tools/testing/selftests/kvm/lib/s390x/processor.c | 13 ++- > tools/testing/selftests/kvm/lib/sparsebit.c | 48 ++++---- > tools/testing/selftests/kvm/lib/ucall_common.c | 3 +- > tools/testing/selftests/kvm/lib/x86_64/processor.c | 45 +++++++- > tools/testing/selftests/kvm/lib/x86_64/sev.c | 114 +++++++++++++++++++ > .../selftests/kvm/x86_64/fix_hypercall_test.c | 27 +++-- > .../kvm/x86_64/private_mem_conversions_test.c | 2 + > .../selftests/kvm/x86_64/sev_migrate_tests.c | 60 +++------- > .../testing/selftests/kvm/x86_64/sev_smoke_test.c | 88 +++++++++++++++ > .../testing/selftests/kvm/x86_64/sync_regs_test.c | 121 +++++++++++++++------ > .../selftests/kvm/x86_64/userspace_msr_exit_test.c | 52 +++------ > .../selftests/kvm/x86_64/vmx_pmu_caps_test.c | 52 ++------- > 26 files changed, 802 insertions(+), 240 deletions(-) > create mode 100644 tools/testing/selftests/kvm/include/aarch64/kvm_util_arch.h > create mode 100644 tools/testing/selftests/kvm/include/kvm_test_harness.h > create mode 100644 tools/testing/selftests/kvm/include/riscv/kvm_util_arch.h > create mode 100644 tools/testing/selftests/kvm/include/s390x/kvm_util_arch.h > create mode 100644 tools/testing/selftests/kvm/include/x86_64/kvm_util_arch.h > create mode 100644 tools/testing/selftests/kvm/include/x86_64/sev.h > create mode 100644 tools/testing/selftests/kvm/lib/x86_64/sev.c > create mode 100644 tools/testing/selftests/kvm/x86_64/sev_smoke_test.c >
On 3/8/24 23:36, Sean Christopherson wrote: > Add SEV(-ES) smoke tests, and start building out infrastructure to utilize the > "core" selftests harness and TAP. In addition to provide TAP output, using the > infrastructure reduces boilerplate code and allows running all testscases in a > test, even if a previous testcase fails (compared with today, where a testcase > failure is terminal for the entire test). Hmm, now I remember why I would have liked to include the AMD SEV changes in 6.9 --- because they get rid of the "subtype" case in selftests. It's not a huge deal, it's just a nicer API, and anyway I'm not going to ask you to rebase on top of my changes; and you couldn't have known that when we talked about it last Wednesday, since the patches are for the moment closely guarded on my hard drive. But it may still be a good reason to sneak those as well in the second week of the 6.9 merge window, though I'm not going to make a fuss if you disagree. Paolo
On Mon, Mar 11, 2024, Paolo Bonzini wrote: > On 3/8/24 23:36, Sean Christopherson wrote: > > Add SEV(-ES) smoke tests, and start building out infrastructure to utilize the > > "core" selftests harness and TAP. In addition to provide TAP output, using the > > infrastructure reduces boilerplate code and allows running all testscases in a > > test, even if a previous testcase fails (compared with today, where a testcase > > failure is terminal for the entire test). > > Hmm, now I remember why I would have liked to include the AMD SEV changes in > 6.9 --- because they get rid of the "subtype" case in selftests. > > It's not a huge deal, it's just a nicer API, and anyway I'm not going to ask > you to rebase on top of my changes; and you couldn't have known that when we > talked about it last Wednesday, since the patches are for the moment closely > guarded on my hard drive. Heh, though it is obvious in hindsight. > But it may still be a good reason to sneak those as well in the second week > of the 6.9 merge window, though I'm not going to make a fuss if you disagree. My preference is still to wait. I would be very surprised if the subtype code gains any users in the next few weeks, i.e. I doubt it'll be any harder to rip out the subtype code in 6.9 versus 6.10. On the other hand, waiting until 6.10 for the SEV changes will give us a bit more time to see how they interact with the SNP and TDX series, e.g. in the off chance there's something in the uAPI that could be done better for SNP and/or TDX.
On Tue, Mar 12, 2024, Sean Christopherson wrote: > On Mon, Mar 11, 2024, Paolo Bonzini wrote: > > On 3/8/24 23:36, Sean Christopherson wrote: > > > Add SEV(-ES) smoke tests, and start building out infrastructure to utilize the > > > "core" selftests harness and TAP. In addition to provide TAP output, using the > > > infrastructure reduces boilerplate code and allows running all testscases in a > > > test, even if a previous testcase fails (compared with today, where a testcase > > > failure is terminal for the entire test). > > > > Hmm, now I remember why I would have liked to include the AMD SEV changes in > > 6.9 --- because they get rid of the "subtype" case in selftests. > > > > It's not a huge deal, it's just a nicer API, and anyway I'm not going to ask > > you to rebase on top of my changes; and you couldn't have known that when we > > talked about it last Wednesday, since the patches are for the moment closely > > guarded on my hard drive. > > Heh, though it is obvious in hindsight. > > > But it may still be a good reason to sneak those as well in the second week > > of the 6.9 merge window, though I'm not going to make a fuss if you disagree. > > My preference is still to wait. I would be very surprised if the subtype code > gains any users in the next few weeks, i.e. I doubt it'll be any harder to rip > out the subtype code in 6.9 versus 6.10. > > On the other hand, waiting until 6.10 for the SEV changes will give us a bit more > time to see how they interact with the SNP and TDX series, e.g. in the off chance > there's something in the uAPI that could be done better for SNP and/or TDX. Though I'll add the belated disclaimer that performance testing is not my strong suit...