On Mon, 2025-01-13 at 10:09 +0800, Binbin Wu wrote: > Lazy check for pending APIC EOI when In-kernel IOAPIC > ----------------------------------------------------- > In-kernel IOAPIC does not receive EOI with AMD SVM AVIC since the processor > accelerates write to APIC EOI register and does not trap if the interrupt > is edge-triggered. So there is a workaround by lazy check for pending APIC > EOI at the time when setting new IOAPIC irq, and update IOAPIC EOI if no > pending APIC EOI. > KVM is also not be able to intercept EOI for TDX guests. > - When APICv is enabled > The code of lazy check for pending APIC EOI doesn't work for TDX because > KVM can't get the status of real IRR and ISR, and the values are 0s in > vIRR and vISR in apic->regs[], kvm_apic_pending_eoi() will always return > false. So the RTC pending EOI will always be cleared when ioapic_set_irq() > is called for RTC. Then userspace may miss the coalesced RTC interrupts. > - When When APICv is disabled > ioapic_lazy_update_eoi() will not be called，then pending EOI status for > RTC will not be cleared after setting and this will mislead userspace to > see coalesced RTC interrupts. > Options: > - Force irqchip split for TDX guests to eliminate the use of in-kernel IOAPIC. > - Leave it as it is, but the use of RTC may not be accurate. Looking at the code, it seems KVM only traps EOI for level-triggered interrupt for in-kernel IOAPIC chip, but IIUC IOAPIC in userspace also needs to be told upon EOI for level-triggered interrupt. I don't know how does KVM works with userspace IOAPIC w/o trapping EOI for level-triggered interrupt, but "force irqchip split for TDX guest" seems not right. I think the problem is level-triggered interrupt, so I think another option is to reject level-triggered interrupt for TDX guest.
