On 12 Dec 2025, at 5:31 AM, David Woodhouse dwmw2@infradead.org wrote:
Hm, I don't like that much. For a start, DISABLE should be fine with the in-kernel IRQCHIP right now (and is the only behaviour that truly makes sense right now).
And my intent was that the in-kernel I/O APIC patch gets included as *part* of this series, otherwise we're making a semantic change to the ENABLE behaviour later.
Also... how does userspace discover the availability of these flags?
(And if you don't include the I/O APIC patch as part of this series, we also need to understand how userspace will later discover that ENABLE can be applied to the in-kernel irqchip too.)
That is a valid point, how about also including the IOAPIC version 0x20 (needs to be tested) and:
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 0ae7f913d782..7b368284ec0b 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -105,6 +105,43 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector) apic_test_vector(vector, apic->regs + APIC_IRR); }
+static bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm) +{ + /* + * Returns true if KVM should advertise Suppress EOI broadcast support + * to the guest. + * + * In split IRQCHIP mode: advertise unless the VMM explicitly disabled + * it. This preserves legacy quirky behavior where KVM advertised the + * capability even though it did not actually suppress EOIs. + * + * In kernel IRQCHIP mode: only advertise if the VMM explicitly + * enabled it (and use the IOAPIC version 0x20). + */ + if (irqchip_split(kvm)) { + return kvm->arch.suppress_eoi_broadcast_mode != + KVM_SUPPRESS_EOI_BROADCAST_DISABLED; + } else { + return kvm->arch.suppress_eoi_broadcast_mode == + KVM_SUPPRESS_EOI_BROADCAST_ENABLED; + } +} + +static bool kvm_lapic_ignore_suppress_eoi_broadcast(struct kvm *kvm) +{ + /* + * Returns true if KVM should ignore the suppress EOI broadcast bit set by + * the guest and broadcast EOIs anyway. + * + * Only returns false when the VMM explicitly enabled Suppress EOI + * broadcast. If disabled by VMM, the bit should be ignored as it is not + * supported. Legacy behavior was to ignore the bit and broadcast EOIs + * anyway. + */ + return kvm->arch.suppress_eoi_broadcast_mode != + KVM_SUPPRESS_EOI_BROADCAST_ENABLED; +} + __read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu); EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_has_noapic_vcpu);
@@ -562,7 +599,7 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu) * IOAPIC. */ if (guest_cpu_cap_has(vcpu, X86_FEATURE_X2APIC) && - !ioapic_in_kernel(vcpu->kvm)) + kvm_lapic_advertise_suppress_eoi_broadcast(vcpu->kvm)) v |= APIC_LVR_DIRECTED_EOI; kvm_lapic_set_reg(apic, APIC_LVR, v); } @@ -1515,6 +1552,17 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector) if (apic->vcpu->arch.highest_stale_pending_ioapic_eoi == vector) kvm_make_request(KVM_REQ_SCAN_IOAPIC, apic->vcpu);
+ /* + * Don't send the EOI to the I/O APIC if the guest has enabled Directed + * EOI, a.k.a. Suppress EOI Broadcasts, in which case the local + * APIC doesn't broadcast EOIs (the guest must EOI the target + * I/O APIC(s) directly). Ignore the suppression if the guest has not + * explicitly enabled Suppress EOI broadcast. + */ + if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) && + !kvm_lapic_ignore_suppress_eoi_broadcast(apic->vcpu->kvm)) + return; + /* Request a KVM exit to inform the userspace IOAPIC. */ if (irqchip_split(apic->vcpu->kvm)) { apic->vcpu->arch.pending_ioapic_eoi = vector;
I am not entirely sure if returning from kvm_ioapic_send_eoi() early is correct for kernel IOAPIC. The original code (which is now redundant) does this very late in kvm_ioapic_update_eoi_one().