All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jim Mattson <jmattson@google.com>, kvm list <kvm@vger.kernel.org>
Subject: Re: [PATCH 1/2 v2] KVM: nVMX: KVM needs to unset "unrestricted guest" VM-execution control in vmcs02 if vmcs12 doesn't set it
Date: Fri, 17 Apr 2020 18:55:45 -0700	[thread overview]
Message-ID: <20200418015545.GB15609@linux.intel.com> (raw)
In-Reply-To: <d49ce960-92f9-85eb-4cfb-d533a956223e@oracle.com>

On Fri, Apr 17, 2020 at 06:29:23PM -0700, Krish Sadhukhan wrote:
> 
> On 4/16/20 2:18 AM, Paolo Bonzini wrote:
> >On 15/04/20 22:18, Jim Mattson wrote:
> >>>Has anyone worked through all the flows to verify this won't break any
> >>>assumptions with respect to enable_unrestricted_guest?  I would be
> >>>(pleasantly) surprised if this was sufficient to run L2 without
> >>>unrestricted guest when it's enabled for L1, e.g. vmx_set_cr0() looks
> >>>suspect.
> >>I think you're right to be concerned.
> >Thirded, but it shouldn't be too hard.  Basically,
> >enable_unrestricted_guest must be moved into loaded_vmcs for this to
> >work.  It may be more work to write the test cases for L2 real mode <->
> >protected mode switch, which do not entirely fit into the vmx_tests.c
> >framework (but with the v2 tests it should not be hard to adapt).
> 
> 
> OK, I will move enable_unrestricted_guest  to loaded_vmcs.

Hmm, enable_unrestricted_guest doesn't _need_ to be moved to loaded_vmcs,
L1 can never diverge from enable_unrestricted_guest.  E.g. the main control
variable can stay global, we just need a flag in nested_vmx to override the
main control.  A simple wrapper can then take care of the check, e.g.

  static inline bool is_unrestricted_guest(struct kvm_vcpu *vcpu)
  {
	return enable_unrestricted_guest && (!is_guest_mode(vcpu) ||
	       to_vmx(vcpu)->nested.unrestricted_guest);
  }

Putting the flag in loaded_vmcs might be more performant?  My guess is it'd
be in the noise, at which point I'd rather have it be clear the override is
only possible/necessary for nested guests.

> I also see that enable_ept controls the setting of
> enable_unrestricted_guest. Perhaps both need to be moved to loaded_vmcs ?

No, letting L1 disable EPT in L0 would be pure insanity, and the overall
paging mode of L2 is already reflected in the MMU.

The dependency on EPT is that VMX requires paging of some form and
unrestricted guest allows entering non-root with CR0.PG=0, i.e. requires EPT
be enabled.

> About testing, I am thinking the test will first vmlaunch L2 in real mode or
> in protected mode, then vmexit on vmcall and then vmresume in the other
> mode. Is that how the test should flow ?
> 
> >
> >Paolo
> >

  reply	other threads:[~2020-04-18  1:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 18:30 [PATCH 0/2 v2] kvm-unit-test: nVMX: Test Selector and Base Address fields of Guest Segment registers Krish Sadhukhan
2020-04-15 18:30 ` [PATCH 1/2 v2] KVM: nVMX: KVM needs to unset "unrestricted guest" VM-execution control in vmcs02 if vmcs12 doesn't set it Krish Sadhukhan
2020-04-15 19:30   ` Sean Christopherson
2020-04-15 20:18     ` Jim Mattson
2020-04-16  9:18       ` Paolo Bonzini
2020-04-18  1:29         ` Krish Sadhukhan
2020-04-18  1:55           ` Sean Christopherson [this message]
2020-04-18  9:53             ` Paolo Bonzini
2020-04-20 15:12               ` Sean Christopherson
2020-04-28  7:25               ` Krish Sadhukhan
2020-04-28  8:14                 ` Paolo Bonzini
2020-04-28 17:38                   ` Krish Sadhukhan
2020-04-28 18:00                     ` Jim Mattson
2020-04-15 18:30 ` [PATCH 2/2 v2] kvm-unit-tests: nVMX: Test Selector and Base Address fields of Guest Segment Registers on vmentry of nested guests Krish Sadhukhan

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=20200418015545.GB15609@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.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 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.