Re: [RFC PATCH v3 02/27] x86/apic: Drop savic_eoi() in favor of native_apic_msr_eoi() for Secure AVIC

[Sean Christopherson]

On Thu, Oct 08, 2026, Naveen N Rao wrote:
> On Mon, Oct 05, 2026 at 11:16:51PM -0700, Sean Christopherson wrote:
> > On Tue, Jul 14, 2026, Naveen N Rao wrote:
> > > On Mon, Jul 13, 2026 at 12:43:45PM -0500, Tom Lendacky wrote:
> > > > On 7/8/26 01:32, Naveen N Rao (AMD) wrote:
> > > > > Drop savic_eoi() in favor of using the native helper that writes to the
> > > > > APIC_EOI MSR. savic_eoi() was added mainly to be able to handle
> > > > > level-triggered interrupts. However, it relies on APIC_TMR indicating a
> > > > > vector to be level-triggered, but APIC_TMR can never have a bit set
> > > > > since it is only updated when the LAPIC accepts a level-triggered
> > > > > interrupt. In the case of a Secure AVIC SEV-SNP guest, all
> > > > > level-triggered interrupt sources are in the VMM (emulated IOAPIC
> > > > > primarily) and KVM accepts them on behalf of the guest resulting in the
> > > > > APIC_TMR in KVM APIC backing page having a bit set. This is never seen
> > > > > by the guest, which has its own private APIC backing page. As such, the
> > > > > savic_eoi() handler is dead code. Remove it.
> > > > > 
> > > > > Fixes: 43b6687ac877 ("x86/apic: Handle EOI writes for Secure AVIC guests")
> > > > > Signed-off-by: Naveen N Rao (AMD) <naveen@xxxxxxxxxx>
> > > > 
> > > > Another guest change which should be separate from this series.
> > > 
> > > Yes, I have called this out in the cover letter. I see now that I should 
> > > have used a better subject for the cover letter though.
> > > 
> > > > 
> > > > Is this causing issues with this hypervisor support or is just code that
> > > > is never invoked? Do other hypervisors behave the same way and will
> > > > removing this break them?
> > > 
> > > This is code that is never invoked and is independent of the hypervisor.  
> > > No impact to hypervisor code.
> > 
> > Doesn't that mean level-triggered interrupts are fundamentally incompatible with
> > Secure AVIC?
> 
> I think so, at least from the hypervisor front. Secure AVIC uses a 
> guest-private, encrypted APIC backing page. KVM's APIC_TMR is not 
> visible to the guest and the only injection mechanism is via 
> VMCB->Requested_IRR field, which can only carry vectors. This means 
> APIC_TMR in the guest backing page will never be set. So, all guest 
> writes to APIC_EOI are accelerated and do not cause an exit.
> 
> The guest could track level-triggered interrupts and notify the 
> hypervisor though. But, it isn't clear to me that is necessarily better.  
> Linux already seems to have a fallback which works for I/O APIC (see 
> below).
> 
> I believe TDX has similar restrictions?

No.  VMX lets the hypervisor select exactly which vectors will trigger a VM-Exit
on EOI, via a dedicated bitmap.  Only SVM's approach of keying off the TMR is
problematic.  FWIW, SVM's approach is flawed in general because it makes assumptions
about hypervisor behavior that don't hold true, e.g. see the games that have to
be played to deal with RTC tick stuffing when it's wired up as an edge-triggered
interrupt.