> On 9 Mar 2026, at 11:12 AM, Khushit Shah <[email protected]> wrote: > > This is an RFC posted for design feedback rather than merge. > > Problem > ------- > > In split-irqchip mode, KVM unconditionally advertises x2APIC Suppress EOI > Broadcast (SEOIB) support to the guest. This is wrong in two ways: > > - IOAPIC v0x11 has no EOI register, so advertising SEOIB is incorrect. > - Even with IOAPIC v0x20, KVM ignores the guest's suppression request > and continues to broadcast LAPIC EOIs to the userspace IOAPIC. > > This can cause interrupt storms in guests that rely on Directed EOI > semantics (e.g. Windows with Credential Guard, which hangs during boot). > > KVM fix > ------- > > KVM now exposes two new x2APIC API flags to give userspace control: > > - KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST > - KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST > > This patch > ---------- > > This patch wires those flags into QEMU via a machine-level field > (kvm_lapic_seoib_state) with three policy states: > > - SEOIB_STATE_QUIRKED (default): legacy behavior, no flags set > - SEOIB_STATE_RESPECTED: advertise SEOIB and honor guest suppression > - SEOIB_STATE_NOT_ADVERTISED: hide SEOIB from guest (for IOAPIC v0x11) > > The current implementation automatically selects a policy based on IOAPIC > version at VM power-on time, and migrates the state as a VMState subsection. > > Design challenges > ----------------- > > The KVM x2APIC API is one-way: once a flag is set, it cannot be reverted > back to the quirked state (consistent with other x2APIC API flags). This > has several implications: > > - During incoming migration, we must defer setting the flags until after > the SEOIB state is loaded from the migration stream, since we cannot > know the source VM's policy in advance. > > - Snapshot restore (loadvm) is problematic: if the running VM has already > set enabled/disabled, restoring a QUIRKED snapshot cannot revert the > KVM state. QMP/HMP loadvm makes this worse since it cannot be detected > at init time. > > - The flags only take effect when kvm_apic_set_version() is called inside > KVM, which happens from limited paths such as IOAPIC initialization or > APIC state setting. This requires setting the flags before IOAPIC is > initialized, necessitating fetching the IOAPIC version from global > properties rather than from the initialized device. > > - Automatic policy selection (current approach) changes behavior for > existing machine types without user opt-in, breaking migratability > from a new QEMU to an older QEMU for the same machine type. > > - Machine-type gating (restrict to 10.2+) helps with older machine types, > but still breaks migration to a destination with an older kernel that > lacks the SEOIB API, again without user opt-in. > > Preferred direction > ------------------- > > Given the above, I am leaning toward a KVM accelerator property (for > example, `seoib-policy=respected|not-advertised|quirked`) with the default > being quirked. > > This approach: > > - The user explicitly opts in. But requires user to understand/configure > the property. > - Works with any machine type, no machine-type gating needed. > - No need to fetch the IOAPIC version from globals. > > > Note: The current implementation also does not handle the QMP/HMP > loadvm corner cases. > > I would appreciate feedback on the preferred approach. > > Changes in v2: > - Update flags in patch description to match kernel naming. > > Khushit Shah (1): > target/i386/kvm: Configure proper KVM SEOIB behavior > > hw/i386/x86-common.c | 99 ++++++++++++++++++++++++++++++++++++ > hw/i386/x86.c | 1 + > hw/intc/ioapic.c | 2 - > include/hw/i386/x86.h | 12 +++++ > include/hw/intc/ioapic.h | 2 + > include/system/system.h | 1 + > system/vl.c | 5 ++ > target/i386/kvm/kvm.c | 43 ++++++++++++++++ > target/i386/kvm/kvm_i386.h | 12 +++++ > target/i386/kvm/trace-events | 4 ++ > 10 files changed, 179 insertions(+), 2 deletions(-) > > -- > 2.39.3 >
Missed maintainers in the initial mail, fixed.
