From: Tom Lendacky <thomas.lendacky@amd.com>
To: Sean Christopherson <seanjc@google.com>,
Srikanth Aithal <sraithal@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jim Mattson <jmattson@google.com>,
Naveen N Rao <naveen@kernel.org>,
"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 12:36:09 -0500 [thread overview]
Message-ID: <947bf241-d149-4933-874a-de96aeb73dff@amd.com> (raw)
In-Reply-To: <abBSPkKmMiFCfKek@google.com>
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).
Thanks,
Tom
> need to trap CR8 writes because hardware will update the backing page. I'm guessing
> Windows doesn't support running as an SEV-ES guest, which is no one has noticed.
>
> Actually, it's worse than that. sync_cr8_to_lapic() will straight up clobber the
> backing page. Presumably hardware never actually uses TPR from the AVIC backing
> page, but it's still gross. sync_lapic_to_cr8() is also beyond useless.
>
> And all of sync code should pivot on guest_state_protected, not sev_es_guest().
>
> For now, I'll just post the above (assuming it fixes the issue). But this code
> needs some love sooner than later.
>
next prev parent reply other threads:[~2026-03-10 17:36 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 [this message]
2026-03-10 17:48 ` Naveen N Rao
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=947bf241-d149-4933-874a-de96aeb73dff@amd.com \
--to=thomas.lendacky@amd.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.szmigiero@oracle.com \
--cc=naveen@kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=sraithal@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
Powered by JetHome