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

[Sean Christopherson]

On Tue, Nov 03, 2026, Naveen N Rao wrote:
> On Thu, Oct 15, 2026 at 06:31:53AM -0700, Sean Christopherson wrote:
> > 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.
> 
> Agreed w.r.t VMX vs. SVM.
> 
> However, as far as I can tell, for TDX guests, the EOI exit bitmap is 
> not honored and so, level-triggered interrupts are incompatible with 
> those too, no?

Oh, right, duh, I see what you're saying.  Correct, TDX (deliberately, IIRCK)
doesn't support level-triggered interrupts.