All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Thomas Prescher <thomas.prescher@cyberus-technology.de>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>,
	 "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	 Julian Stecklina <julian.stecklina@cyberus-technology.de>,
	 "tglx@linutronix.de" <tglx@linutronix.de>,
	"bp@alien8.de" <bp@alien8.de>,
	 "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] KVM: nVMX: fix CR4_READ_SHADOW when L0 updates CR4 during a signal
Date: Thu, 18 Apr 2024 11:36:57 -0700	[thread overview]
Message-ID: <ZiFoSdKY7nrh7cfL@google.com> (raw)
In-Reply-To: <70f9f3f847e614cbb95be4c011ecb0a5cbd2ef34.camel@cyberus-technology.de>

On Thu, Apr 18, 2024, Thomas Prescher wrote:
> You are right. After your pointers and looking at the nesting code
> again, I think I know what to do. Just to make sure I understand this
> correctly: 
> 
> If L0 exits with L2 state, KVM_GET_NESTED_STATE will have
> KVM_STATE_NESTED_RUN_PENDING set in the flags field.

Not necessarily.  KVM_STATE_NESTED_GUEST_MODE is the flag that says "L2 state is
loaded", the NESTED_RUN_PENDING flag is effectively a modifier on top of that.

KVM_STATE_NESTED_RUN_PENDING is set when userspace interrupts KVM in the middle
of nested VM-Enter emulation.  In that case, KVM needs to complete emulation of
the VM-Enter instruction (VMLAUNCH, VMRESUME, or VMRUN) before doing anything.
I.e. KVM has loaded L2 state and is committed to completing VM-Enter, but hasn't
actually done so yet.

In retrospect, KVM probably should have forced userspace to call back into KVM to
complete emulation before allowing KVM_GET_NESTED_STATE to succeed, but it's a
minor blip.

> So when we restore the vCPU state after a vmsave/vmload cycle, we don't need
> to update anything in kvm_run.s.regs because KVM will enter the L2
> immediately.  Is that correct?

No?  Presumably your touching vCPU state, otherwise you wouldn't be doing
vmsave/vmload.  And if you touch vCPU state, then you need to restore the old
state for things to work.

Again, what are you trying to do, at a higher level?  I.e. _why_ are you doing
a save/restore cycle?  If it's for something akin to live migration, where you
need to save and restore *everything*, then stating the obvious, you need to
save and restore everything in KVM too, which includes nested state.

      reply	other threads:[~2024-04-18 18:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-16 12:35 [PATCH 1/2] KVM: nVMX: fix CR4_READ_SHADOW when L0 updates CR4 during a signal Julian Stecklina
2024-04-16 12:35 ` [PATCH 2/2] KVM: nVMX: remove unnecessary CR4_READ_SHADOW write Julian Stecklina
2024-04-16 14:35 ` [PATCH 1/2] KVM: nVMX: fix CR4_READ_SHADOW when L0 updates CR4 during a signal Sean Christopherson
2024-04-16 15:08   ` Thomas Prescher
2024-04-16 15:17     ` Sean Christopherson
2024-04-16 17:31       ` Thomas Prescher
2024-04-16 18:07         ` Sean Christopherson
2024-04-17 13:05           ` Thomas Prescher
2024-04-17 16:11             ` Sean Christopherson
2024-04-17 16:28               ` Sean Christopherson
2024-04-18 13:48                 ` Thomas Prescher
2024-04-18 18:28                   ` Sean Christopherson
2024-05-08 13:27                     ` Thomas Prescher
2024-04-18 13:46               ` Thomas Prescher
2024-04-18 18:36                 ` Sean Christopherson [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=ZiFoSdKY7nrh7cfL@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=julian.stecklina@cyberus-technology.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.prescher@cyberus-technology.de \
    --cc=x86@kernel.org \
    /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.