| Message ID | 20230923102019.29444-1-phil@philjordan.eu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [kvm-unit-tests] x86/apic: Gates test_pv_ipi on KVM cpuid, not test device | expand |
On Sat, Sep 23, 2023, Phil Dennis-Jordan wrote: > This changes the test for the KVM IPI hypercall API to be skipped if the > relevant cpuid feature bit is not set or if the KVM cpuid leaf is > missing, rather than the presence of the test device. The latter is an > unreliable inference on non-KVM platforms. > > It also adds a skip report when these tests are skipped. > > Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> > --- > lib/x86/processor.h | 19 +++++++++++++++++++ > x86/apic.c | 9 ++++++++- > 2 files changed, 27 insertions(+), 1 deletion(-) > > diff --git a/lib/x86/processor.h b/lib/x86/processor.h > index 44f4fd1e..9a4c0d26 100644 > --- a/lib/x86/processor.h > +++ b/lib/x86/processor.h > @@ -284,6 +284,13 @@ static inline bool is_intel(void) > #define X86_FEATURE_VNMI (CPUID(0x8000000A, 0, EDX, 25)) > #define X86_FEATURE_AMD_PMU_V2 (CPUID(0x80000022, 0, EAX, 0)) > > +/* > + * Hypervisor specific leaves (KVM, ...) > + * See: > + * https://kernel.org/doc/html/latest/virt/kvm/x86/cpuid.html > + */ > +#define X86_KVM_FEATURE_PV_SEND_IPI (CPUID(0x40000001, 0, EAX, 11)) We could actually define this using the uapi headers, then there's no need to reference the kernel docs, e.g. #define X86_FEATURE_KVM_PV_SEND_IPI (CPUID(KVM_CPUID_FEATURES, 0, EAX, KVM_FEATURE_PV_SEND_IPI) > + > static inline bool this_cpu_has(u64 feature) > { > u32 input_eax = feature >> 32; > @@ -299,6 +306,18 @@ static inline bool this_cpu_has(u64 feature) > return ((*(tmp + (output_reg % 32))) & (1 << bit)); > } > > +static inline bool kvm_feature_flags_supported(void) > +{ > + struct cpuid c; > + > + c = cpuid_indexed(0x40000000, 0); > + return > + c.b == 0x4b4d564b > + && c.c == 0x564b4d56 > + && c.d == 0x4d I would much prefer to provide something similar to the kernel's hypervisor_cpuid_base(), and then use KVM_SIGNATURE to match the signature. And assert that KVM is placed at its default base for tests that require KVM paravirt features, i.e. disallow relocating KVM to e.g. 0x40000100 to make room for Hyper-V. Something like this (completely untested) static inline u32 get_hypervisor_cpuid_base(const char *sig) { u32 base, signature[3]; if (!this_cpu_has(X86_FEATURE_HYPERVISOR)) return 0; for (base = 0x40000000; base < 0x40010000; base += 0x100) { cpuid(base, &eax, &signature[0], &signature[1], &signature[2]); if (!memcmp(sig, signature, 12)) return base; } return 0; } static inline bool is_hypervisor_kvm(void) { u32 base = get_hypervisor_cpuid_base(KVM_SIGNATURE); if (!base) return 0; /* * Require that KVM be placed at its default base so that macros can be * used to query individual KVM feature bits. */ TEST_ASSERT(base == KVM_CPUID_SIGNATURE); return true; } > + && (c.a >= 0x40000001 || c.a == 0); Why allow 0? Though I think we probably forego this check entirely. > +} > + > struct far_pointer32 { > u32 offset; > u16 selector; > diff --git a/x86/apic.c b/x86/apic.c > index dd7e7834..525e08fd 100644 > --- a/x86/apic.c > +++ b/x86/apic.c > @@ -30,6 +30,11 @@ static bool is_xapic_enabled(void) > return (rdmsr(MSR_IA32_APICBASE) & (APIC_EN | APIC_EXTD)) == APIC_EN; > } > > +static bool is_kvm_ipi_hypercall_supported(void) > +{ > + return kvm_feature_flags_supported() && this_cpu_has(X86_KVM_FEATURE_PV_SEND_IPI); > +} > + > static void test_lapic_existence(void) > { > u8 version; > @@ -658,8 +663,10 @@ static void test_pv_ipi(void) > int ret; > unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 = 0x0; > > - if (!test_device_enabled()) > + if (!is_kvm_ipi_hypercall_supported()) { I would rather open code the two independent checks, e.g. if (!is_hypervisor_kvm() || !this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) Or alternatively, provide a generic helper in processor.h to handle the hypervisor check, e.g. static inline this_cpu_has_kvm_feature(...) Though if we go that route it probably makes sense to play nice with relocating the base since it would be quite easy to do so. > + report_skip("PV IPIs testing (No KVM IPI hypercall flag in cpuid)"); > return; > + } > > asm volatile("vmcall" : "=a"(ret) :"a"(KVM_HC_SEND_IPI), "b"(a0), "c"(a1), "d"(a2), "S"(a3)); > report(!ret, "PV IPIs testing"); > -- > 2.36.1 >
+KVM and Paolo Please keep the mailing list Cc'd so that other can participate in the conversation, and so that the mails are archived. Adding Paolo, who I believe is still not subscribed to kvm@ :-) On Tue, Sep 26, 2023, Phil Dennis-Jordan wrote: > Hi Sean, > > Thanks for taking a look at this. > > On Mon, Sep 25, 2023 at 5:18 PM Sean Christopherson <seanjc@google.com> wrote: > > On Sat, Sep 23, 2023, Phil Dennis-Jordan wrote: > > > +#define X86_KVM_FEATURE_PV_SEND_IPI (CPUID(0x40000001, 0, EAX, 11)) > > > > We could actually define this using the uapi headers, then there's no need to > > reference the kernel docs, e.g. > > > > #define X86_FEATURE_KVM_PV_SEND_IPI (CPUID(KVM_CPUID_FEATURES, 0, EAX, KVM_FEATURE_PV_SEND_IPI) > > That sounds sensible, but those symbols are #defined in headers that > are currently only routinely available on Linux systems. I know this > is the *KVM* unit test suite, but it's definitely also very useful > elsewhere. > (My specific motivation for the patch is that on macOS/HVF, Qemu's > software APIC implementation is used. The current implementation for > that turns out to be a massive perf bottleneck and very much > not-spec-compliant, so I've been improving it. This test suite has > been very useful for testing/verifying my work, but this IPI test had > to be disabled.) Ah, right. > A few options I can think of: > > 1. I notice x86/hyperv.h has a bunch of similar #defines. We could > collect only the KVM-related x86 constants and helper functions we > actually need in a corresponding x86/kvm.h. I see there's a kvmclock.h > for the KVM clock already - that could either be renamed and expanded > in scope, or left separate. kvmclock.h is essentially #2, it's a copy of arch/x86/include/asm/pvclock-abi.h from the kernel. > 2. Bring a copy of the necessary KVM uapi header file(s) into the > repo, slightly hacked up to cut down on transitive dependencies. It > looks like lib/linux/*.h might already be similar instances for other > Linux bits. Qemu also does this. This has my vote, though I'd strongly prefer not to strip out anything unless it's absolutely necessary to get KUT to compile. Grabbing entire files should make it easier to maintain the copy+pasted code as future updates to re-sync will hopefully add just the new features. The attached half-baked patch adds everything except the base "is this KVM?" check and has only been compile tested on x86, feel free to use it as a starting point (I wanted to get the basic gist compiling to make sure I wasn't leading you completely astray) > > > + && (c.a >= 0x40000001 || c.a == 0); > > > > Why allow 0? Though I think we probably forego this check entirely. > > "Note also that old hosts set eax value to 0x0. This should be > interpreted as if the value was 0x40000001. " according to > https://www.kernel.org/doc/html/v5.7/virt/kvm/cpuid.html > Though I suppose "old hosts" are probably VERY old and probably don't > expose the IPI hypercall… Ha, so your the one that reads the documentation ;-) > > > @@ -658,8 +663,10 @@ static void test_pv_ipi(void) > > > int ret; > > > unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 = 0x0; > > > > > > - if (!test_device_enabled()) > > > + if (!is_kvm_ipi_hypercall_supported()) { > > > > I would rather open code the two independent checks, e.g. > > > > if (!is_hypervisor_kvm() || !this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) > > Makes sense, especially so we don't have to keep rechecking whether > we're on KVM in case we end up testing for more KVM feature flags at > some point. > > > Or alternatively, provide a generic helper in processor.h to handle the hypervisor > > check, e.g. > > > > static inline this_cpu_has_kvm_feature(...) > > > > Though if we go that route it probably makes sense to play nice with relocating > > the base since it would be quite easy to do so. > > Probably overkill as long as we only have this one instance? Yeah, probably.
On Tue, Sep 26, 2023 at 6:08 PM Sean Christopherson <seanjc@google.com> wrote: > Please keep the mailing list Cc'd so that other can participate in the conversation, > and so that the mails are archived. Sorry! I've now enabled reply-to-all by default so I can't forget again. > > 2. Bring a copy of the necessary KVM uapi header file(s) into the > > repo, slightly hacked up to cut down on transitive dependencies. It > > looks like lib/linux/*.h might already be similar instances for other > > Linux bits. Qemu also does this. > > This has my vote, though I'd strongly prefer not to strip out anything unless it's > absolutely necessary to get KUT to compile. Grabbing entire files should make it > easier to maintain the copy+pasted code as future updates to re-sync will hopefully > add just the new features. Yup, makes sense. > The attached half-baked patch adds everything except the base "is this KVM?" > check and has only been compile tested on x86, feel free to use it as a starting > point (I wanted to get the basic gist compiling to make sure I wasn't leading you > completely astray) The attachment doesn't seem to have made it, would you mind trying again? Then I'll put together a v2 of the patch based on that. Thanks, Phil
On Wed, Sep 27, 2023, Phil Dennis-Jordan wrote: > On Tue, Sep 26, 2023 at 6:08=E2=80=AFPM Sean Christopherson <seanjc@googl= e.com> wrote: > > The attached half-baked patch adds everything except the base "is this = KVM?" > > check and has only been compile tested on x86, feel free to use it as a= starting > > point (I wanted to get the basic gist compiling to make sure I wasn't l= eading you > > completely astray) >=20 > The attachment doesn't seem to have made it, would you mind trying > again? Then I'll put together a v2 of the patch based on that. Gah, sorry. This is why I usually inline patches, I forget to actually att= ach the darn things 50% of the time.
On Wed, Sep 27, 2023 at 4:18 PM Sean Christopherson <seanjc@google.com> wrote: > Gah, sorry. This is why I usually inline patches, I forget to actually att= > ach > the darn things 50% of the time. Thanks for that, and apologies for only just getting around to taking a closer look. Out of the box, this doesn't build on macOS at least, as that's missing <linux/types.h>. I tried going down the rabbit hole of pulling that header and its various transitive dependencies in from the Linux tree, but ended up in a horrible mess where those headers try to define things like bool, which libcflat has already pulled in from the standard system headers (on Linux I suspect the libc #include guards match up with the stuff in <linux/*>, so there's no issue). On macOS, the problem is easy to resolve via a cut-down types.h with a minimal set of definitions: #include <libcflat.h> typedef u8 __u8; typedef u32 __u32; typedef u64 __u64; typedef s64 __s64; …but I assume that breaks things on Linux. I'm thinking something like this might work: #if __LINUX__ #include_next <linux/types.h> #else [minimal types.h definitions] #endif But I'm unsure if that's really the direction you'd want to go with this? (And I still need to set myself up with a dev environment on a physical Linux box that I can test this all on.) Another option might be a symlinked linux/types.h created by ./configure if not running on Linux? On the substance of the patch itself: > unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 = 0x0; > - if (!test_device_enabled()) > + if (!this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) So this check will (erroneously IMO) succeed if we're running on a non-KVM hypervisor which happens to expose a flag at bit 11 of ecx on CPUID leaf 0x40000001 page 0, right? With this in mind, your earlier idea seems better: if (!is_hypervisor_kvm() || !this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) { So I've gone ahead and made an attempt at fixing up your draft implementation of is_hypervisor_kvm() below. The partial struct memcmp in get_hypervisor_cpuid_base is a bit icky; I'm not sure if that's worth fixing up at the cost of readability. Thoughts? (I've attached the full set of WIP changes on top of yours as another patch. Feel free to squash it all into one if you decide to run with it.) Thanks, Phil diff --git a/lib/x86/processor.h b/lib/x86/processor.h index 7a7048f9..3d3930c8 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -240,6 +240,7 @@ static inline bool is_intel(void) #define X86_FEATURE_XSAVE (CPUID(0x1, 0, ECX, 26)) #define X86_FEATURE_OSXSAVE (CPUID(0x1, 0, ECX, 27)) #define X86_FEATURE_RDRAND (CPUID(0x1, 0, ECX, 30)) +#define X86_FEATURE_HYPERVISOR (CPUID(0x1, 0, ECX, 31)) #define X86_FEATURE_MCE (CPUID(0x1, 0, EDX, 7)) #define X86_FEATURE_APIC (CPUID(0x1, 0, EDX, 9)) #define X86_FEATURE_CLFLUSH (CPUID(0x1, 0, EDX, 19)) @@ -286,7 +287,8 @@ static inline bool is_intel(void) #define X86_FEATURE_VNMI (CPUID(0x8000000A, 0, EDX, 25)) #define X86_FEATURE_AMD_PMU_V2 (CPUID(0x80000022, 0, EAX, 0)) -#define X86_FEATURE_KVM_PV_SEND_IPI (CPUID(KVM_CPUID_FEATURES, 0, EAX, KVM_FEATURE_PV_SEND_IPI)) +#define X86_FEATURE_KVM_PV_SEND_IPI \ + (CPUID(KVM_CPUID_FEATURES, 0, EAX, KVM_FEATURE_PV_SEND_IPI)) static inline bool this_cpu_has(u64 feature) { @@ -303,6 +305,40 @@ static inline bool this_cpu_has(u64 feature) return ((*(tmp + (output_reg % 32))) & (1 << bit)); } +static inline u32 get_hypervisor_cpuid_base(const char *sig) +{ + u32 base; + struct cpuid signature; + + if (!this_cpu_has(X86_FEATURE_HYPERVISOR)) + return 0; + + for (base = 0x40000000; base < 0x40010000; base += 0x100) { + signature = cpuid(base); + + if (!memcmp(sig, &signature.b, 12)) + return base; + } + + return 0; +} + +static inline bool is_hypervisor_kvm(void) +{ + u32 base = get_hypervisor_cpuid_base(KVM_SIGNATURE); + + if (!base) + return false; + + /* + * Require that KVM be placed at its default base so that macros can be + * used to query individual KVM feature bits. + */ + assert_msg(base == KVM_CPUID_SIGNATURE, + "Expect KVM at its default cpuid base (now at: 0x%x)", base); + return true; +} + struct far_pointer32 { u32 offset; u16 selector;
I've now got around to testing this patch on Linux/KVM. The thing I was worried about, my <linux/types.h> wrapper, appears to work exactly as intended, everything builds nicely on Linux. So that aspect of the patch is now a matter of taste. However, I *have* run into a minor snag with this proposed change: the X86_FEATURE_KVM_PV_SEND_IPI bit isn't actually enabled by default. It looks like it needs to be specified explicitly as a +kvm-pv-ipi flag in the -cpu option on the Qemu command line. KVM itself still handles the IPI hypercall either way, as there's another flag you'd have to opt into for only handling advertised hypercalls. I think the cleanest way to fix this is probably to add +kvm-pv-ipi to the apic-split, x2apic, and xapic test suites in x86/unittests.cfg and keep the strict feature flag check in the test code. As I understand it, Qemu will filter the feature bit if the underlying KVM implementation doesn't support it, so that would appear to give us the best compatibility, except perhaps for Qemu versions that predate this flag, which will presumably fail to run the test suites altogether. Alternatively, we could simply check whether we're running on KVM and skip the feature bit check entirely - it certainly wouldn't make any additional assumptions; as of right now, the master branch already assumes we're running on KVM *and* the KVM implementation supports the IPI HC. Dropping the feature bit check doesn't make the patch tangibly smaller though. I'll wait a couple of days for any other suggestions or objections, and in the absence of such I'll roll your draft patch, my modifications, and the x86/unittests.cfg tweaks into a v2 patch and re-submit. (And I'll tag it with you, Sean, as Co-authored-by:) Thanks, Phil On Thu, 5 Oct 2023 at 22:19, Phil Dennis-Jordan <lists@philjordan.eu> wrote: > > On Wed, Sep 27, 2023 at 4:18 PM Sean Christopherson <seanjc@google.com> wrote: > > Gah, sorry. This is why I usually inline patches, I forget to actually att= > > ach > > the darn things 50% of the time. > > Thanks for that, and apologies for only just getting around to taking > a closer look. Out of the box, this doesn't build on macOS at least, > as that's missing <linux/types.h>. I tried going down the rabbit hole > of pulling that header and its various transitive dependencies in from > the Linux tree, but ended up in a horrible mess where those headers > try to define things like bool, which libcflat has already pulled in > from the standard system headers (on Linux I suspect the libc #include > guards match up with the stuff in <linux/*>, so there's no issue). > On macOS, the problem is easy to resolve via a cut-down types.h with a > minimal set of definitions: > > #include <libcflat.h> > typedef u8 __u8; > typedef u32 __u32; > typedef u64 __u64; > typedef s64 __s64; > > …but I assume that breaks things on Linux. I'm thinking something like > this might work: > > #if __LINUX__ > #include_next <linux/types.h> > #else > [minimal types.h definitions] > #endif > > But I'm unsure if that's really the direction you'd want to go with > this? (And I still need to set myself up with a dev environment on a > physical Linux box that I can test this all on.) > > Another option might be a symlinked linux/types.h created by > ./configure if not running on Linux? > > > On the substance of the patch itself: > > > unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 = 0x0; > > - if (!test_device_enabled()) > > + if (!this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) > > So this check will (erroneously IMO) succeed if we're running on a > non-KVM hypervisor which happens to expose a flag at bit 11 of ecx on > CPUID leaf 0x40000001 page 0, right? With this in mind, your earlier > idea seems better: > > if (!is_hypervisor_kvm() || > !this_cpu_has(X86_FEATURE_KVM_PV_SEND_IPI)) { > > So I've gone ahead and made an attempt at fixing up your draft > implementation of is_hypervisor_kvm() below. > > The partial struct memcmp in get_hypervisor_cpuid_base is a bit icky; > I'm not sure if that's worth fixing up at the cost of readability. > > > Thoughts? > > (I've attached the full set of WIP changes on top of yours as another > patch. Feel free to squash it all into one if you decide to run with > it.) > > Thanks, > Phil > > > diff --git a/lib/x86/processor.h b/lib/x86/processor.h > index 7a7048f9..3d3930c8 100644 > --- a/lib/x86/processor.h > +++ b/lib/x86/processor.h > @@ -240,6 +240,7 @@ static inline bool is_intel(void) > #define X86_FEATURE_XSAVE (CPUID(0x1, 0, ECX, 26)) > #define X86_FEATURE_OSXSAVE (CPUID(0x1, 0, ECX, 27)) > #define X86_FEATURE_RDRAND (CPUID(0x1, 0, ECX, 30)) > +#define X86_FEATURE_HYPERVISOR (CPUID(0x1, 0, ECX, 31)) > #define X86_FEATURE_MCE (CPUID(0x1, 0, EDX, 7)) > #define X86_FEATURE_APIC (CPUID(0x1, 0, EDX, 9)) > #define X86_FEATURE_CLFLUSH (CPUID(0x1, 0, EDX, 19)) > @@ -286,7 +287,8 @@ static inline bool is_intel(void) > #define X86_FEATURE_VNMI (CPUID(0x8000000A, 0, EDX, 25)) > #define X86_FEATURE_AMD_PMU_V2 (CPUID(0x80000022, 0, EAX, 0)) > > -#define X86_FEATURE_KVM_PV_SEND_IPI (CPUID(KVM_CPUID_FEATURES, 0, > EAX, KVM_FEATURE_PV_SEND_IPI)) > +#define X86_FEATURE_KVM_PV_SEND_IPI \ > + (CPUID(KVM_CPUID_FEATURES, 0, EAX, KVM_FEATURE_PV_SEND_IPI)) > > static inline bool this_cpu_has(u64 feature) > { > @@ -303,6 +305,40 @@ static inline bool this_cpu_has(u64 feature) > return ((*(tmp + (output_reg % 32))) & (1 << bit)); > } > > +static inline u32 get_hypervisor_cpuid_base(const char *sig) > +{ > + u32 base; > + struct cpuid signature; > + > + if (!this_cpu_has(X86_FEATURE_HYPERVISOR)) > + return 0; > + > + for (base = 0x40000000; base < 0x40010000; base += 0x100) { > + signature = cpuid(base); > + > + if (!memcmp(sig, &signature.b, 12)) > + return base; > + } > + > + return 0; > +} > + > +static inline bool is_hypervisor_kvm(void) > +{ > + u32 base = get_hypervisor_cpuid_base(KVM_SIGNATURE); > + > + if (!base) > + return false; > + > + /* > + * Require that KVM be placed at its default base so that macros can be > + * used to query individual KVM feature bits. > + */ > + assert_msg(base == KVM_CPUID_SIGNATURE, > + "Expect KVM at its default cpuid base (now at: 0x%x)", base); > + return true; > +} > + > struct far_pointer32 { > u32 offset; > u16 selector;
diff --git a/lib/x86/processor.h b/lib/x86/processor.h index 44f4fd1e..9a4c0d26 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -284,6 +284,13 @@ static inline bool is_intel(void) #define X86_FEATURE_VNMI (CPUID(0x8000000A, 0, EDX, 25)) #define X86_FEATURE_AMD_PMU_V2 (CPUID(0x80000022, 0, EAX, 0)) +/* + * Hypervisor specific leaves (KVM, ...) + * See: + * https://kernel.org/doc/html/latest/virt/kvm/x86/cpuid.html + */ +#define X86_KVM_FEATURE_PV_SEND_IPI (CPUID(0x40000001, 0, EAX, 11)) + static inline bool this_cpu_has(u64 feature) { u32 input_eax = feature >> 32; @@ -299,6 +306,18 @@ static inline bool this_cpu_has(u64 feature) return ((*(tmp + (output_reg % 32))) & (1 << bit)); } +static inline bool kvm_feature_flags_supported(void) +{ + struct cpuid c; + + c = cpuid_indexed(0x40000000, 0); + return + c.b == 0x4b4d564b + && c.c == 0x564b4d56 + && c.d == 0x4d + && (c.a >= 0x40000001 || c.a == 0); +} + struct far_pointer32 { u32 offset; u16 selector; diff --git a/x86/apic.c b/x86/apic.c index dd7e7834..525e08fd 100644 --- a/x86/apic.c +++ b/x86/apic.c @@ -30,6 +30,11 @@ static bool is_xapic_enabled(void) return (rdmsr(MSR_IA32_APICBASE) & (APIC_EN | APIC_EXTD)) == APIC_EN; } +static bool is_kvm_ipi_hypercall_supported(void) +{ + return kvm_feature_flags_supported() && this_cpu_has(X86_KVM_FEATURE_PV_SEND_IPI); +} + static void test_lapic_existence(void) { u8 version; @@ -658,8 +663,10 @@ static void test_pv_ipi(void) int ret; unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 = 0x0; - if (!test_device_enabled()) + if (!is_kvm_ipi_hypercall_supported()) { + report_skip("PV IPIs testing (No KVM IPI hypercall flag in cpuid)"); return; + } asm volatile("vmcall" : "=a"(ret) :"a"(KVM_HC_SEND_IPI), "b"(a0), "c"(a1), "d"(a2), "S"(a3)); report(!ret, "PV IPIs testing");
This changes the test for the KVM IPI hypercall API to be skipped if the relevant cpuid feature bit is not set or if the KVM cpuid leaf is missing, rather than the presence of the test device. The latter is an unreliable inference on non-KVM platforms. It also adds a skip report when these tests are skipped. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> --- lib/x86/processor.h | 19 +++++++++++++++++++ x86/apic.c | 9 ++++++++- 2 files changed, 27 insertions(+), 1 deletion(-)