From: "Andersen, John" <john.s.andersen@intel.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: corbet@lwn.net, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>, mingo <mingo@redhat.com>,
bp <bp@alien8.de>,
hpa@zytor.com, shuah@kernel.org,
Sean Christopherson <sean.j.christopherson@intel.com>,
rick.p.edgecombe@intel.com, kvm <kvm@vger.kernel.org>,
kernel-hardening@lists.openwall.com
Subject: Re: [kvm-unit-tests PATCH] x86: Add control register pinning tests
Date: Thu, 18 Jun 2020 13:31:57 +0000 [thread overview]
Message-ID: <20200618133157.GA23@258ff54ff3c0> (raw)
In-Reply-To: <FAFB5DA6-FA6F-4A1A-AB10-4B99F314B23D@gmail.com>
On Wed, Jun 17, 2020 at 11:59:10PM -0700, Nadav Amit wrote:
> > On Jun 17, 2020, at 10:08 PM, Andersen, John <john.s.andersen@intel.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 08:18:39PM -0700, Nadav Amit wrote:
> >>> On Jun 17, 2020, at 3:52 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
> >>>
> >>>> On Jun 17, 2020, at 3:46 PM, John Andersen <john.s.andersen@intel.com> wrote:
> >>>>
> >>>> Paravirutalized control register pinning adds MSRs guests can use to
> >>>> discover which bits in CR0/4 they may pin, and MSRs for activating
> >>>> pinning for any of those bits.
> >>>
> >>> [ sni[
> >>>
> >>>> +static void vmx_cr_pin_test_guest(void)
> >>>> +{
> >>>> + unsigned long i, cr0, cr4;
> >>>> +
> >>>> + /* Step 1. Skip feature detection to skip handling VMX_CPUID */
> >>>> + /* nop */
> >>>
> >>> I do not quite get this comment. Why do you skip checking whether the
> >>> feature is enabled? What happens if KVM/bare-metal/other-hypervisor that
> >>> runs this test does not support this feature?
> >>
> >> My bad, I was confused between the nested checks and the non-nested ones.
> >>
> >> Nevertheless, can we avoid situations in which
> >> rdmsr(MSR_KVM_CR0_PIN_ALLOWED) causes #GP when the feature is not
> >> implemented? Is there some protocol for detection that this feature is
> >> supported by the hypervisor, or do we need something like rdmsr_safe()?
> >
> > Ah, yes we can. By checking the CPUID for the feature bit. Thanks for pointing
> > this out, I was confused about this. I was operating under the assumption that
> > the unit tests assume the features in the latest kvm/next are present and
> > available when the unit tests are being run.
> >
> > I'm happy to add the check, but I haven't see anywhere else where a
> > KVM_FEATURE_ was checked for. Which is why it doesn't check in this patch. As
> > soon as I get an answer from you or anyone else as to if the unit tests assume
> > that the features in the latest kvm/next are present and available or not when
> > the unit tests are being run I'll modify if necessary.
>
> I would appreciate if you add a check of CPUID and not run the test if the
> feature is not supported.
>
> I run the tests on bare-metal (and other non-KVM environment) from time to
> time. Doing so allows to find bugs in tests due to wrong assumptions of KVM
> test developers. Liran runs the tests using QEMU/WHPX (non-KVM). So allowing
> the tests to run on non-KVM environments is important, at least for some of
> us, and benefits KVM as well.
>
> While I can disable this specific test using the test parameters, I prefer
> that the test will first check the environment they run on. Debugging test
> failures on bare-metal is hard enough without the paravirt stuff noise.
>
Great point! I'll add the check
prev parent reply other threads:[~2020-06-18 14:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-17 22:46 [kvm-unit-tests PATCH] x86: Add control register pinning tests John Andersen
2020-06-17 22:52 ` Nadav Amit
2020-06-18 3:18 ` Nadav Amit
2020-06-18 5:08 ` Andersen, John
2020-06-18 6:59 ` Nadav Amit
2020-06-18 13:31 ` Andersen, John [this message]
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=20200618133157.GA23@258ff54ff3c0 \
--to=john.s.andersen@intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=hpa@zytor.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sean.j.christopherson@intel.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.