From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Cc: wanpengli@tencent.com, rkrcmar@redhat.com, kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH] x86/apic: Skip pv ipi test if hcall not available
Date: Tue, 22 Oct 2019 10:46:11 +0200 [thread overview]
Message-ID: <875zkh1830.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <34e212a851eb0d490fad49f8b712b2c6e652db76.camel@gmail.com>
Suraj Jitindar Singh <sjitindarsingh@gmail.com> writes:
> Hi,
>
> On Fri, 2019-10-18 at 18:53 +0200, Vitaly Kuznetsov wrote:
>> Suraj Jitindar Singh <sjitindarsingh@gmail.com> writes:
>>
>> > From: Suraj Jitindar Singh <surajjs@amazon.com>
>> >
>> > The test in x86/apic.c named test_pv_ipi is used to test for a
>> > kernel
>> > bug where a guest making the hcall KVM_HC_SEND_IPI can trigger an
>> > out of
>> > bounds access.
>> >
>> > If the host doesn't implement this hcall then the out of bounds
>> > access
>> > cannot be triggered.
>> >
>> > Detect the case where the host doesn't implement the
>> > KVM_HC_SEND_IPI
>> > hcall and skip the test when this is the case, as the test doesn't
>> > apply.
>> >
>> > Output without patch:
>> > FAIL: PV IPIs testing
>> >
>> > With patch:
>> > SKIP: PV IPIs testing: h-call not available
>> >
>> > Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
>> > ---
>> > x86/apic.c | 11 +++++++++++
>> > 1 file changed, 11 insertions(+)
>> >
>> > diff --git a/x86/apic.c b/x86/apic.c
>> > index eb785c4..bd44b54 100644
>> > --- a/x86/apic.c
>> > +++ b/x86/apic.c
>> > @@ -8,6 +8,8 @@
>> > #include "atomic.h"
>> > #include "fwcfg.h"
>> >
>> > +#include <linux/kvm_para.h>
>> > +
>> > #define MAX_TPR 0xf
>> >
>> > static void test_lapic_existence(void)
>> > @@ -638,6 +640,15 @@ static void test_pv_ipi(void)
>> > unsigned long a0 = 0xFFFFFFFF, a1 = 0, a2 = 0xFFFFFFFF, a3 =
>> > 0x0;
>> >
>> > asm volatile("vmcall" : "=a"(ret) :"a"(KVM_HC_SEND_IPI),
>> > "b"(a0), "c"(a1), "d"(a2), "S"(a3));
>> > + /*
>> > + * Detect the case where the hcall is not implemented by the
>> > hypervisor and
>> > + * skip this test if this is the case. Is the hcall isn't
>> > implemented then
>> > + * the bug that this test is trying to catch can't be
>> > triggered.
>> > + */
>> > + if (ret == -KVM_ENOSYS) {
>> > + report_skip("PV IPIs testing: h-call not available");
>> > + return;
>> > + }
>> > report("PV IPIs testing", !ret);
>> > }
>>
>> Should we be checking CPUID bit (KVM_FEATURE_PV_SEND_IPI) instead?
>>
>
> That's also an option. It will produce the same result.
>
Generally yes, but CPUID announcement has its own advantages: when a
feature bit is set we know the hypercall *must* exist so -KVM_ENOSYS
would be a bug (think of a theoretical situation when the hypercall
starts to return -KVM_ENOSYS erroneously - how do we catch this?)
> Would that be the preferred approach or is the method used in the
> current patch ok?
I'm not insisting, let's leave it up to Paolo :-)
--
Vitaly
next prev parent reply other threads:[~2019-10-22 8:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 23:50 [kvm-unit-tests PATCH] x86/apic: Skip pv ipi test if hcall not available Suraj Jitindar Singh
2019-10-18 16:53 ` Vitaly Kuznetsov
2019-10-21 22:50 ` Suraj Jitindar Singh
2019-10-22 8:46 ` Vitaly Kuznetsov [this message]
2019-10-22 8:53 ` Wanpeng Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zkh1830.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=rkrcmar@redhat.com \
--cc=sjitindarsingh@gmail.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox