linux-kernel - Re: [PATCH v4] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <B45DB519-3B04-46F7-894E-42A44DF2FC8E@nutanix.com>
Date: Fri, 12 Dec 2025 07:08:23 +0000
From: Khushit Shah <khushit.shah@...anix.com>
To: David Woodhouse <dwmw2@...radead.org>
CC: "seanjc@...gle.com" <seanjc@...gle.com>,
        "pbonzini@...hat.com"
	<pbonzini@...hat.com>,
        "kai.huang@...el.com" <kai.huang@...el.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "hpa@...or.com" <hpa@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        Jon
 Kohler <jon@...anix.com>,
        Shaju Abraham <shaju.abraham@...anix.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v4] KVM: x86: Add x2APIC "features" to control EOI
 broadcast suppression


> On 12 Dec 2025, at 5:31 AM, David Woodhouse <dwmw2@...radead.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().