All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Cathy Avery <cavery@redhat.com>,
	Emanuele Giuseppe Esposito <eesposit@redhat.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from SMM
Date: Thu, 24 Jun 2021 18:36:12 +0300	[thread overview]
Message-ID: <613c6a638bbb91d5841162747c700b164d994d88.camel@redhat.com> (raw)
In-Reply-To: <6fc7213f-9836-0245-39bb-a05554c85680@amd.com>

On Thu, 2021-06-24 at 09:32 -0500, Tom Lendacky wrote:
> On 6/24/21 5:38 AM, Paolo Bonzini wrote:
> > On 24/06/21 10:20, Maxim Levitsky wrote:
> > > Something else to note, just for our information is that KVM
> > > these days does vmsave/vmload to VM_HSAVE_PA to store/restore
> > > the additional host state, something that is frowned upon in the spec,
> > > but there is some justification of doing this in the commit message,
> > > citing an old spec which allowed this.
> > 
> > True that.  And there is no mention in the specification for VMRUN that
> > the host state-save area is a subset of the VMCB format (i.e., that it
> > uses VMCB offsets for whatever subset of the state it saves in the VMCB),
> > so the spec reference in the commit message is incorrect.  It would be
> > nice if the spec guaranteed that.  Michael, Tom?
> 
> So that is (now) stated in APM volume 2, Appendix B in the paragraph after
> Table B-3, where it starts "The format of the host save area is identical
> to the guest save area described in the table below, except that ..."

This is a very good find! I wish it was written in the commit message
of commit that added that vmsave/vmload to VM_HSAVE_PA area.

Maybe we should add a comment to the code pointing to this location of the APM.

Thanks,
	Best regards,
		Maxim Levitsky

> 
> Thanks,
> Tom
> 
> > In fact, Vitaly's patch *will* overwrite the vmsave/vmload parts of
> > VM_HSAVE_PA, and it will store the L2 values rather than the L1 values,
> > because KVM always does its vmload/vmrun/vmsave sequence using
> > vmload(vmcs01) and vmsave(vmcs01)!  So that has to be changed to use code
> > similar to svm_set_nested_state (which can be moved to a separate function
> > and reused):
> > 
> >         dest->es = src->es;
> >         dest->cs = src->cs;
> >         dest->ss = src->ss;
> >         dest->ds = src->ds;
> >         dest->gdtr = src->gdtr;
> >         dest->idtr = src->idtr;
> >         dest->rflags = src->rflags | X86_EFLAGS_FIXED;
> >         dest->efer = src->efer;
> >         dest->cr0 = src->cr0;
> >         dest->cr3 = src->cr3;
> >         dest->cr4 = src->cr4;
> >         dest->rax = src->rax;
> >         dest->rsp = src->rsp;
> >         dest->rip = src->rip;
> >         dest->cpl = 0;
> > 
> > 
> > Paolo
> > 



  reply	other threads:[~2021-06-24 15:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23  7:44 [PATCH RFC] KVM: nSVM: Fix L1 state corruption upon return from SMM Vitaly Kuznetsov
2021-06-23  9:39 ` Paolo Bonzini
2021-06-23 11:39   ` Maxim Levitsky
2021-06-23 12:00     ` Paolo Bonzini
2021-06-23 13:01   ` Maxim Levitsky
2021-06-23 13:07     ` Maxim Levitsky
2021-06-23 13:32       ` Vitaly Kuznetsov
2021-06-23 14:41         ` Maxim Levitsky
2021-06-23 16:10           ` Sean Christopherson
2021-06-23 16:21             ` Sean Christopherson
2021-06-23 20:37               ` Paolo Bonzini
2021-06-24  7:41                 ` Vitaly Kuznetsov
2021-06-24  8:20                 ` Maxim Levitsky
2021-06-24 10:38                   ` Paolo Bonzini
2021-06-24 14:32                     ` Tom Lendacky
2021-06-24 15:36                       ` Maxim Levitsky [this message]
2021-06-23 13:21     ` Paolo Bonzini
2021-06-23 14:06       ` Maxim Levitsky

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=613c6a638bbb91d5841162747c700b164d994d88.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=cavery@redhat.com \
    --cc=eesposit@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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.