mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, Jim Mattson <jmattson@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Joerg Roedel <joro@8bytes.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org
Subject: Re: [PATCH 1/4] KVM: x86: mark synthetic SMM vmexit as SVM_EXIT_SW
Date: Tue, 01 Mar 2022 19:13:00 +0200	[thread overview]
Message-ID: <2fddbfd6b6e68f3f8e972536c27a87ffadbe1911.camel@redhat.com> (raw)
In-Reply-To: <Yh5KTtLhRyfmx/ZF@google.com>

On Tue, 2022-03-01 at 16:31 +0000, Sean Christopherson wrote:
> On Tue, Mar 01, 2022, Maxim Levitsky wrote:
> > Use a dummy unused vmexit reason to mark the 'VM exit' that is happening
> > when kvm exits to handle SMM, which is not a real VM exit.
> 
> Why not use "62h VMEXIT_SMI"?

Because VMEXIT_SMI is real vmexit which happens when L1 intercepts #SMI
And here nested_svm_vmexit is abused to just exit guest mode without vmexit.

> 
> > This makes it a bit easier to read the KVM trace, and avoids
> > other potential problems.
> 
> What other potential problems?

The fact that we have a stale VM exit reason in vmcb without this
patch which can be in theory consumed somewhere down the road.

This stale vm exit reason also appears in the tracs which is
very misleading.

Best regards,
	Maxim Levitsky

> 
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  arch/x86/kvm/svm/svm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index 7038c76fa8410..c08fd7f4f3414 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -4218,7 +4218,7 @@ static int svm_enter_smm(struct kvm_vcpu *vcpu, char *smstate)
> >  	svm->vmcb->save.rsp = vcpu->arch.regs[VCPU_REGS_RSP];
> >  	svm->vmcb->save.rip = vcpu->arch.regs[VCPU_REGS_RIP];
> >  
> > -	ret = nested_svm_vmexit(svm);
> > +	ret = nested_svm_simple_vmexit(svm, SVM_EXIT_SW);
> >  	if (ret)
> >  		return ret;
> >  
> > -- 
> > 2.26.3
> > 



  reply	other threads:[~2022-03-01 17:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 13:55 [PATCH 0/4] SVM fixes + apic fix Maxim Levitsky
2022-03-01 13:55 ` [PATCH 1/4] KVM: x86: mark synthetic SMM vmexit as SVM_EXIT_SW Maxim Levitsky
2022-03-01 16:31   ` Sean Christopherson
2022-03-01 17:13     ` Maxim Levitsky [this message]
2022-03-09 15:46       ` Paolo Bonzini
2022-03-01 13:55 ` [PATCH 2/4] KVM: x86: SVM: disable preemption in avic_refresh_apicv_exec_ctrl Maxim Levitsky
2022-03-01 17:15   ` Sean Christopherson
2022-03-01 17:20     ` Maxim Levitsky
2022-03-01 17:23       ` Paolo Bonzini
2022-03-01 13:55 ` [PATCH 3/4] KVM: x86: SVM: use vmcb01 in avic_init_vmcb Maxim Levitsky
2022-03-01 16:21   ` Sean Christopherson
2022-03-01 17:25     ` Maxim Levitsky
2022-03-01 17:35       ` Sean Christopherson
2022-03-09 15:48       ` Paolo Bonzini
2022-03-15 12:27         ` Maxim Levitsky
2022-03-01 13:55 ` [PATCH 4/4] KVM: x86: lapic: don't allow to set non default apic id when not using x2apic api Maxim Levitsky
2022-03-01 16:56   ` Sean Christopherson
2022-03-01 17:09     ` Maxim Levitsky
2022-03-01 17:46       ` Sean Christopherson
2022-03-01 17:56         ` Maxim Levitsky
2022-03-02 11:50           ` Maxim Levitsky
2022-03-03 16:51             ` Sean Christopherson
2022-03-03 18:15               ` Maxim Levitsky
2022-03-03 19:38                 ` Sean Christopherson
2022-03-03 19:49                   ` Sean Christopherson
2022-03-04 10:54                     ` 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=2fddbfd6b6e68f3f8e972536c27a87ffadbe1911.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®