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

[Naveen N Rao]

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?

> I don't see how the emulated I/O APIC will ever get an EOI.

My understanding is that the guest will have to signal EOI to the I/O 
APIC directly. Linux seems to do so (ioapic_ack_level() calls 
eoi_ioapic_pin() if APIC_TMR is not set for a level-triggered 
interrupt).


- Naveen