Re: [RFC PATCH v3 5/6] KVM: SVM: Add support for AMD IOMMU Guest APIC Physical Processor Interrupt (GAPPI)

On Mon, Aug 10, 2026, Sairaj Kodilkar wrote:
> On 7/13/2026 4:41 PM, [email protected] wrote:
> > [Severity: High]
> > Can an unprivileged user-space process trigger this WARN_ON?
> > 
> > When a vCPU is created, svm->gappi_cpu is initialized to -1 in
> > avic_init_vcpu(). It is only set to a valid CPU ID later during
> > __avic_vcpu_load().
> > 
> > If host user-space configures device interrupt routing via the KVM_IRQFD ioctl
> > before the vCPU runs, avic_pi_update_irte() is invoked. This will pass the
> > uninitialized svm->gappi_cpu (-1) down to this function, hitting the WARN_ON.
> > If the host has panic_on_warn enabled, this allows host userspace to trigger
> > a kernel panic.
> 
> This is a valid concern.
> 
> If host userspace attaches a bypass IRQ targeting a vCPU that has never
> been loaded. Functionally, there is nothing to do in that window. A vCPU
> that has never been loaded cannot be blocking, so no GAPPI wakeup is
> required. The IOMMU still posts the interrupt into the vAPIC backing
> page, and the pending IRR is evaluated at the first VMRUN after
> avic_vcpu_load(), which is also where the IRTE gets a valid Destination
> and IsRun = 1.
> 
> This can be resolved by assigning a arbitrary gappi destination, without
> actually updating the gappi wakeup list of that CPU.

With the disclaimer that I haven't look super closely at this series, and haven't
thought too deeply about the feature itself either...

Why are we doing anything different than what VMX does?  vCPUs on the wakeup
list when they block, and come off the list when they wakeup.  It's literally
one flow that's guarantee to pair put()+load(), and the logic for manipulating
the list is quite simple as a result.

Going a step further, why is GAPPI not sharing code with VMX Posted Interupts?
At a glance, the only meaningful difference in the wakeup flow is the "should
this particular vCPU be awakened".