public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Naveen N Rao <naveen@kernel.org>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Sean Christopherson <seanjc@google.com>,
	 Srikanth Aithal <sraithal@amd.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org,
	Jim Mattson <jmattson@google.com>,
	 "Maciej S . Szmigiero" <maciej.szmigiero@oracle.com>
Subject: Re: [PATCH 2/2] KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
Date: Tue, 10 Mar 2026 23:18:16 +0530	[thread overview]
Message-ID: <abBYiODdL4405KbB@blrnaveerao1> (raw)
In-Reply-To: <947bf241-d149-4933-874a-de96aeb73dff@amd.com>

On Tue, Mar 10, 2026 at 12:36:09PM -0500, Tom Lendacky wrote:
> On 3/10/26 12:17, Sean Christopherson wrote:
> > On Tue, Mar 10, 2026, Srikanth Aithal wrote:
> >>
> >> Hello Sean,
> >>
> >> From next-20260304 onwards [1], including recent next kernel next-20260309,
> >> booting an SEV-ES guest on AMD EPYC Turin and AMD EPYC Genoa has been
> >> failing. However, on EPYC Milan, the SEV-ES guest boots fine.
> > 
> > ...
> > 
> >> Bisecting shows that this commit is the first bad one. When I revert it, I
> >> am able to boot the SEV-ES guest successfully on both Turin and Genoa
> >> platforms:
> >>
> >> e992bf67bcbab07a7f59963b2c4ed32ef65c8431 is the first bad commit
> >> commit e992bf67bcbab07a7f59963b2c4ed32ef65c8431
> >> Author: Sean Christopherson <seanjc@google.com>
> >> Date:   Tue Feb 3 11:07:10 2026 -0800
> > 
> > Gah, I hate how KVM manages intercepts for SEV-ES+.  Though to a large extent I
> > blame the architecture for not simply making CR{0,4,8} intercept trap-like.
> > Side topic, is the host actually allowed to trap CR3 writes?  That seems like a
> > huge gaping security flaw, especially for SNP+.
> > 
> > Anyways, this should fix the immediate problem.
> > 
> > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> > index 33172f0e986b..b6072872b785 100644
> > --- a/arch/x86/kvm/svm/avic.c
> > +++ b/arch/x86/kvm/svm/avic.c
> > @@ -237,7 +237,8 @@ static void avic_deactivate_vmcb(struct vcpu_svm *svm)
> >         vmcb->control.int_ctl &= ~(AVIC_ENABLE_MASK | X2APIC_MODE_MASK);
> >         vmcb->control.avic_physical_id &= ~AVIC_PHYSICAL_MAX_INDEX_MASK;
> >  
> > -       svm_set_intercept(svm, INTERCEPT_CR8_WRITE);
> > +       if (!sev_es_guest(svm->vcpu.kvm))
> > +               svm_set_intercept(svm, INTERCEPT_CR8_WRITE);
> >  
> >         /*
> >          * If running nested and the guest uses its own MSR bitmap, there
> > 
> > Argh!  The more I look at this code, the more frustrated I get.  The unconditional
> > setting of TRAP_CR8_WRITE for SEV-ES+ is flawed.  When AVIC is enabled, KVM doesn't
> 
> AVIC is disabled for SEV guests (see __sev_guest_init() and the
> kvm_set_apicv_inhibit(kvm, APICV_INHIBIT_REASON_SEV) call at the end of
> the function).

AVIC gets inhibited globally, but continues to be enabled on 
vcpu_create() opportunistically -- see kvm_create_lapic(). It only gets 
disabled later during vcpu setup via 
vcpu_reset()->svm_vcpu_reset()->init_vmcb()->avic_init_vmcb()


- Naveen


  reply	other threads:[~2026-03-10 17:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 19:07 [PATCH 0/2] KVM: SVM: Fix CR8 intercpetion woes with AVIC Sean Christopherson
2026-02-03 19:07 ` [PATCH 1/2] KVM: SVM: Initialize AVIC VMCB fields if AVIC is enabled with in-kernel APIC Sean Christopherson
2026-02-05  4:21   ` Jim Mattson
2026-02-06 14:00   ` Naveen N Rao
2026-02-06 18:17     ` Sean Christopherson
2026-02-09 10:23       ` Naveen N Rao
2026-02-09 21:36         ` Sean Christopherson
2026-02-03 19:07 ` [PATCH 2/2] KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated Sean Christopherson
2026-02-05  4:22   ` Jim Mattson
2026-02-06 17:11   ` Naveen N Rao
2026-02-06 17:55     ` Sean Christopherson
2026-03-10 15:41   ` Aithal, Srikanth
2026-03-10 17:17     ` Sean Christopherson
2026-03-10 17:36       ` Tom Lendacky
2026-03-10 17:48         ` Naveen N Rao [this message]
2026-03-10 18:00           ` Naveen N Rao
2026-03-10 18:12           ` Tom Lendacky
2026-03-10 18:35             ` Sean Christopherson
2026-03-10 21:41               ` Tom Lendacky
2026-03-10 21:58                 ` Sean Christopherson
2026-03-10 22:33                   ` Tom Lendacky
2026-03-10 22:40                     ` Sean Christopherson
2026-03-11 13:43                       ` Tom Lendacky
2026-03-11 17:39                     ` Paolo Bonzini
2026-03-05 17:07 ` [PATCH 0/2] KVM: SVM: Fix CR8 intercpetion woes with AVIC Sean Christopherson

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=abBYiODdL4405KbB@blrnaveerao1 \
    --to=naveen@kernel.org \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.szmigiero@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=sraithal@amd.com \
    --cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox