All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Krish Sadhukhan <krish.sadhukhan@oracle.com>,
	kvm@vger.kernel.org, rkrcmar@redhat.com, jmattson@google.com
Subject: Re: [PATCH 0/5] KVM: nVMX: Skip vmentry checks that are necessary only if VMCS12 is dirty
Date: Wed, 10 Jul 2019 09:15:19 -0700	[thread overview]
Message-ID: <20190710161519.GC4348@linux.intel.com> (raw)
In-Reply-To: <4a9a76e4-a40c-58a6-4768-1125f6193c81@redhat.com>

On Wed, Jul 10, 2019 at 04:35:46PM +0200, Paolo Bonzini wrote:
> On 08/07/19 20:17, Sean Christopherson wrote:
> > On Sun, Jul 07, 2019 at 03:11:42AM -0400, Krish Sadhukhan wrote:
> >> The following functions,
> >>
> >> 	nested_vmx_check_controls
> >> 	nested_vmx_check_host_state
> >> 	nested_vmx_check_guest_state
> >>
> >> do a number of vmentry checks for VMCS12. However, not all of these checks need
> >> to be executed on every vmentry. This patchset makes some of these vmentry
> >> checks optional based on the state of VMCS12 in that if VMCS12 is dirty, only
> >> then the checks will be executed. This will reduce performance impact on
> >> vmentry of nested guests.
> > 
> > All of these patches break vmx_set_nested_state(), which sets dirty_vmcs12
> > only after the aforementioned consistency checks pass.
> > 
> > The new nomenclature for the dirty paths is "rare", not "full".
> > 
> > In general, I dislike directly associating the consistency checks with
> > dirty_vmcs12.
> > 
> >   - It's difficult to assess the correctness of the resulting code, e.g.
> >     changing CPU_BASED_VM_EXEC_CONTROL doesn't set dirty_vmcs12, which
> >     calls into question any and all SECONDARY_VM_EXEC_CONTROL checks since
> >     an L1 could toggle CPU_BASED_ACTIVATE_SECONDARY_CONTROLS.
> 
> Yes, CPU-based controls are tricky and should not be changed.  But I
> don't see a big issue apart from the CPU-based controls, and the other
> checks can also be quite expensive---and the point of dirty_vmcs12 and
> shadow VMCS is that we _can_ exclude them most of the time.

No argument there.  My thought was do something like the following so that
all of the "which checks should we perform" logic is consolidated in a
single location and not spread piecemeal throughout the checks themselves.

static int nested_vmx_run(struct kvm_vcpu *vcpu, bool launch)
{
	unsigned long dirty_checks;

	...

	if (vmx->nested.dirty_vmcs12)
		dirty_checks = ENTRY_CONTROLS | EXIT_CONTROLS | HOST_STATE |
			       GUEST_STATE;
	else
		dirty_checks = 0;
}

  reply	other threads:[~2019-07-10 16:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-07  7:11 [PATCH 0/5] KVM: nVMX: Skip vmentry checks that are necessary only if VMCS12 is dirty Krish Sadhukhan
2019-07-07  7:11 ` [PATCH 1/5] KVM: nVMX: Skip VM-Execution Control " Krish Sadhukhan
2019-07-07  7:11 ` [PATCH 2/5] KVM: nVMX: Skip VM-Exit " Krish Sadhukhan
2019-07-10 14:28   ` Paolo Bonzini
2019-07-10 19:18     ` Krish Sadhukhan
2019-07-10 20:11       ` Sean Christopherson
2019-07-07  7:11 ` [PATCH 3/5] KVM: nVMX: Skip VM-Entry Control " Krish Sadhukhan
2019-07-10 16:28   ` Paolo Bonzini
2019-07-07  7:11 ` [PATCH 4/5] KVM: nVMX: Skip Host State Area vmentry " Krish Sadhukhan
2019-07-10 16:26   ` Paolo Bonzini
2019-07-07  7:11 ` [PATCH 5/5] KVM: nVMX: Skip Guest " Krish Sadhukhan
2019-07-10 16:33   ` Paolo Bonzini
2019-07-10 19:34     ` Krish Sadhukhan
2019-07-08 18:17 ` [PATCH 0/5] KVM: nVMX: Skip " Sean Christopherson
2019-07-09 22:50   ` Krish Sadhukhan
2019-07-10 14:35   ` Paolo Bonzini
2019-07-10 16:15     ` Sean Christopherson [this message]
2019-07-10 16:33       ` Paolo Bonzini

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=20190710161519.GC4348@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 \
    --cc=rkrcmar@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.