public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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

      reply	other threads:[~2020-06-18 13:35 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox