| Message ID | 20210422005626.564163-1-ricarkol@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | KVM: x86: Use kernel x86 cpuid utilities in KVM selftests | expand |
On 22/04/21 02:56, Ricardo Koller wrote: > The kernel has a set of utilities and definitions to deal with x86 cpu > features. The x86 KVM selftests don't use them, and instead have > evolved to use differing and ad-hoc methods for checking features. The > advantage of the kernel feature definitions is that they use a format > that embeds the info needed to extract them from cpuid (function, index, > and register to use). > > The first 3 patches massage the related cpuid header files in the kernel > side, then copy them into tools/ so they can be included by selftests. > The last 2 patches replace the tests checking for cpu features to use > the definitions and utilities introduced from the kernel. I queued the first, but I am not sure about the rest. An alternative is to copy over the code from kvm-unit-tests which encodes the leaf/subleaf/register/bit values into the X86_FEATURE_* value. Sharing code with kvm-unit-tests is probably simpler than adding #ifdef __KERNEL__ and keeping the headers in sync. Paolo > Thanks, > Ricardo > > Ricardo Koller (5): > KVM: x86: Move reverse CPUID helpers to separate header file > x86/cpu: Expose CPUID regs, leaf and index definitions to tools > tools headers x86: Copy cpuid helpers from the kernel > KVM: selftests: Introduce utilities for checking x86 features > KVM: selftests: Use kernel x86 cpuid features format > > arch/x86/events/intel/pt.c | 1 + > arch/x86/include/asm/cpufeature.h | 23 +- > arch/x86/include/asm/processor.h | 11 - > arch/x86/kernel/cpu/scattered.c | 2 +- > arch/x86/kernel/cpuid.c | 2 +- > arch/x86/kvm/cpuid.h | 177 +----------- > arch/x86/kvm/reverse_cpuid.h | 185 +++++++++++++ > tools/arch/x86/include/asm/cpufeature.h | 257 ++++++++++++++++++ > tools/arch/x86/include/asm/cpufeatures.h | 3 + > .../selftests/kvm/include/x86_64/cpuid.h | 61 +++++ > .../selftests/kvm/include/x86_64/processor.h | 16 -- > .../kvm/include/x86_64/reverse_cpuid.h | 185 +++++++++++++ > .../selftests/kvm/include/x86_64/svm_util.h | 11 +- > tools/testing/selftests/kvm/lib/x86_64/svm.c | 6 +- > tools/testing/selftests/kvm/lib/x86_64/vmx.c | 5 +- > tools/testing/selftests/kvm/steal_time.c | 5 +- > .../kvm/x86_64/cr4_cpuid_sync_test.c | 23 +- > .../selftests/kvm/x86_64/set_sregs_test.c | 25 +- > .../selftests/kvm/x86_64/vmx_pmu_msrs_test.c | 8 +- > .../kvm/x86_64/vmx_set_nested_state_test.c | 5 +- > .../selftests/kvm/x86_64/xss_msr_test.c | 10 +- > 21 files changed, 749 insertions(+), 272 deletions(-) > create mode 100644 arch/x86/kvm/reverse_cpuid.h > create mode 100644 tools/arch/x86/include/asm/cpufeature.h > create mode 100644 tools/testing/selftests/kvm/include/x86_64/cpuid.h > create mode 100644 tools/testing/selftests/kvm/include/x86_64/reverse_cpuid.h >
On Thu, Apr 22, 2021 at 09:02:09AM +0200, Paolo Bonzini wrote: > On 22/04/21 02:56, Ricardo Koller wrote: > > The kernel has a set of utilities and definitions to deal with x86 cpu > > features. The x86 KVM selftests don't use them, and instead have > > evolved to use differing and ad-hoc methods for checking features. The > > advantage of the kernel feature definitions is that they use a format > > that embeds the info needed to extract them from cpuid (function, index, > > and register to use). > > > > The first 3 patches massage the related cpuid header files in the kernel > > side, then copy them into tools/ so they can be included by selftests. > > The last 2 patches replace the tests checking for cpu features to use > > the definitions and utilities introduced from the kernel. > > I queued the first, but I am not sure about the rest. > > An alternative is to copy over the code from kvm-unit-tests which encodes > the leaf/subleaf/register/bit values into the X86_FEATURE_* value. Sharing > code with kvm-unit-tests is probably simpler than adding #ifdef __KERNEL__ > and keeping the headers in sync. > > Paolo > Thanks. I was thinking about kvm-unit-tests, but the issue is that it would also be a copy. And just like with kernel headers, it would be ideal to keep them in-sync. The advantage of the kernel headers is that it's much easier to check and fix diffs with them. On the other hand, as you say, there would not be any #ifdef stuff with kvm=unit-tests. Please let me know what you think. Thanks, Ricardo > > Thanks, > > Ricardo > > > > Ricardo Koller (5): > > KVM: x86: Move reverse CPUID helpers to separate header file > > x86/cpu: Expose CPUID regs, leaf and index definitions to tools > > tools headers x86: Copy cpuid helpers from the kernel > > KVM: selftests: Introduce utilities for checking x86 features > > KVM: selftests: Use kernel x86 cpuid features format > > > > arch/x86/events/intel/pt.c | 1 + > > arch/x86/include/asm/cpufeature.h | 23 +- > > arch/x86/include/asm/processor.h | 11 - > > arch/x86/kernel/cpu/scattered.c | 2 +- > > arch/x86/kernel/cpuid.c | 2 +- > > arch/x86/kvm/cpuid.h | 177 +----------- > > arch/x86/kvm/reverse_cpuid.h | 185 +++++++++++++ > > tools/arch/x86/include/asm/cpufeature.h | 257 ++++++++++++++++++ > > tools/arch/x86/include/asm/cpufeatures.h | 3 + > > .../selftests/kvm/include/x86_64/cpuid.h | 61 +++++ > > .../selftests/kvm/include/x86_64/processor.h | 16 -- > > .../kvm/include/x86_64/reverse_cpuid.h | 185 +++++++++++++ > > .../selftests/kvm/include/x86_64/svm_util.h | 11 +- > > tools/testing/selftests/kvm/lib/x86_64/svm.c | 6 +- > > tools/testing/selftests/kvm/lib/x86_64/vmx.c | 5 +- > > tools/testing/selftests/kvm/steal_time.c | 5 +- > > .../kvm/x86_64/cr4_cpuid_sync_test.c | 23 +- > > .../selftests/kvm/x86_64/set_sregs_test.c | 25 +- > > .../selftests/kvm/x86_64/vmx_pmu_msrs_test.c | 8 +- > > .../kvm/x86_64/vmx_set_nested_state_test.c | 5 +- > > .../selftests/kvm/x86_64/xss_msr_test.c | 10 +- > > 21 files changed, 749 insertions(+), 272 deletions(-) > > create mode 100644 arch/x86/kvm/reverse_cpuid.h > > create mode 100644 tools/arch/x86/include/asm/cpufeature.h > > create mode 100644 tools/testing/selftests/kvm/include/x86_64/cpuid.h > > create mode 100644 tools/testing/selftests/kvm/include/x86_64/reverse_cpuid.h > > >
On Wed, Apr 28, 2021 at 12:46 PM Ricardo Koller <ricarkol@google.com> wrote: > > On Thu, Apr 22, 2021 at 09:02:09AM +0200, Paolo Bonzini wrote: > > On 22/04/21 02:56, Ricardo Koller wrote: > > > The kernel has a set of utilities and definitions to deal with x86 cpu > > > features. The x86 KVM selftests don't use them, and instead have > > > evolved to use differing and ad-hoc methods for checking features. The > > > advantage of the kernel feature definitions is that they use a format > > > that embeds the info needed to extract them from cpuid (function, index, > > > and register to use). > > > > > > The first 3 patches massage the related cpuid header files in the kernel > > > side, then copy them into tools/ so they can be included by selftests. > > > The last 2 patches replace the tests checking for cpu features to use > > > the definitions and utilities introduced from the kernel. > > > > I queued the first, but I am not sure about the rest. > > > > An alternative is to copy over the code from kvm-unit-tests which encodes > > the leaf/subleaf/register/bit values into the X86_FEATURE_* value. Sharing > > code with kvm-unit-tests is probably simpler than adding #ifdef __KERNEL__ > > and keeping the headers in sync. > > > > Paolo > > > > Thanks. I was thinking about kvm-unit-tests, but the issue is that it > would also be a copy. And just like with kernel headers, it would be > ideal to keep them in-sync. The advantage of the kernel headers is that > it's much easier to check and fix diffs with them. On the other hand, as > you say, there would not be any #ifdef stuff with kvm=unit-tests. Please > let me know what you think. I think the kvm-unit-tests implementation is superior to the kernel implementation, but that's probably because I suggested it. Still, I think there's an argument to be made that selftests, unlike kvm-unit-tests, are part of the kernel distribution and should be consistent with the kernel where possible. Paolo?
On 29/06/21 19:28, Jim Mattson wrote: >> Thanks. I was thinking about kvm-unit-tests, but the issue is that it >> would also be a copy. And just like with kernel headers, it would be >> ideal to keep them in-sync. The advantage of the kernel headers is that >> it's much easier to check and fix diffs with them. On the other hand, as >> you say, there would not be any #ifdef stuff with kvm=unit-tests. Please >> let me know what you think. > > I think the kvm-unit-tests implementation is superior to the kernel > implementation, but that's probably because I suggested it. Still, I > think there's an argument to be made that selftests, unlike > kvm-unit-tests, are part of the kernel distribution and should be > consistent with the kernel where possible. > > Paolo? I also prefer the kvm-unit-tests implementation, for what it's worth... Let's see what the code looks like? Paolo
On Thu, Jul 08, 2021 at 06:50:41PM +0200, Paolo Bonzini wrote: > On 29/06/21 19:28, Jim Mattson wrote: > > > Thanks. I was thinking about kvm-unit-tests, but the issue is that it > > > would also be a copy. And just like with kernel headers, it would be > > > ideal to keep them in-sync. The advantage of the kernel headers is that > > > it's much easier to check and fix diffs with them. On the other hand, as > > > you say, there would not be any #ifdef stuff with kvm=unit-tests. Please > > > let me know what you think. > > > > I think the kvm-unit-tests implementation is superior to the kernel > > implementation, but that's probably because I suggested it. Still, I > > think there's an argument to be made that selftests, unlike > > kvm-unit-tests, are part of the kernel distribution and should be > > consistent with the kernel where possible. > > > > Paolo? > > I also prefer the kvm-unit-tests implementation, for what it's worth... > Let's see what the code looks like? I'm not sure I understand the question. You mean: let's see how this looks using kvm-unit-tests headers? If that's the case I can work on a v3 using kvm-unit-tests. Thanks, Ricardo > > Paolo >
On 08/07/21 19:21, Ricardo Koller wrote: >> I also prefer the kvm-unit-tests implementation, for what it's worth... >> Let's see what the code looks like? > I'm not sure I understand the question. You mean: let's see how this > looks using kvm-unit-tests headers? If that's the case I can work on a > v3 using kvm-unit-tests. Yes, exactly. Thanks! Paolo
On Thu, Jul 08, 2021 at 07:57:24PM +0200, Paolo Bonzini wrote: > On 08/07/21 19:21, Ricardo Koller wrote: > > > I also prefer the kvm-unit-tests implementation, for what it's worth... > > > Let's see what the code looks like? > > I'm not sure I understand the question. You mean: let's see how this > > looks using kvm-unit-tests headers? If that's the case I can work on a > > v3 using kvm-unit-tests. > > Yes, exactly. Thanks! Cool, will give it a try and send a v3. Thanks, Ricardo > > Paolo >