Extract the suppress EOI broadcast (Directed EOI) logic into helper
functions and move the check from kvm_ioapic_update_eoi_one() to
kvm_ioapic_update_eoi() (required for a later patch). Prepare
kvm_ioapic_send_eoi() to honor Suppress EOI Broadcast in split IRQCHIP
mode.
Introduce two helper functions:
- kvm_lapic_advertise_suppress_eoi_broadcast(): determines whether KVM
should advertise Suppress EOI Broadcast support to the guest
- kvm_lapic_respect_suppress_eoi_broadcast(): determines whether KVM should
honor the guest's request to suppress EOI broadcasts
This refactoring prepares for I/O APIC version 0x20 support and userspace
control of suppress EOI broadcast behavior.
Signed-off-by: Khushit Shah <khushit.shah@nutanix.com>
---
arch/x86/kvm/ioapic.c | 12 +++++++---
arch/x86/kvm/lapic.c | 53 ++++++++++++++++++++++++++++++++++++-------
arch/x86/kvm/lapic.h | 3 +++
3 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 2c2783296aed..6bf8d110aece 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -545,7 +545,6 @@ static void kvm_ioapic_update_eoi_one(struct kvm_vcpu *vcpu,
int trigger_mode,
int pin)
{
- struct kvm_lapic *apic = vcpu->arch.apic;
union kvm_ioapic_redirect_entry *ent = &ioapic->redirtbl[pin];
/*
@@ -560,8 +559,7 @@ static void kvm_ioapic_update_eoi_one(struct kvm_vcpu *vcpu,
kvm_notify_acked_irq(ioapic->kvm, KVM_IRQCHIP_IOAPIC, pin);
spin_lock(&ioapic->lock);
- if (trigger_mode != IOAPIC_LEVEL_TRIG ||
- kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI)
+ if (trigger_mode != IOAPIC_LEVEL_TRIG)
return;
ASSERT(ent->fields.trig_mode == IOAPIC_LEVEL_TRIG);
@@ -591,10 +589,16 @@ static void kvm_ioapic_update_eoi_one(struct kvm_vcpu *vcpu,
void kvm_ioapic_update_eoi(struct kvm_vcpu *vcpu, int vector, int trigger_mode)
{
int i;
+ struct kvm_lapic *apic = vcpu->arch.apic;
struct kvm_ioapic *ioapic = vcpu->kvm->arch.vioapic;
spin_lock(&ioapic->lock);
rtc_irq_eoi(ioapic, vcpu, vector);
+
+ if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) &&
+ kvm_lapic_respect_suppress_eoi_broadcast(ioapic->kvm))
+ goto out;
+
for (i = 0; i < IOAPIC_NUM_PINS; i++) {
union kvm_ioapic_redirect_entry *ent = &ioapic->redirtbl[i];
@@ -602,6 +606,8 @@ void kvm_ioapic_update_eoi(struct kvm_vcpu *vcpu, int vector, int trigger_mode)
continue;
kvm_ioapic_update_eoi_one(vcpu, ioapic, trigger_mode, i);
}
+
+out:
spin_unlock(&ioapic->lock);
}
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 0ae7f913d782..2c24fd8d815f 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -105,6 +105,39 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector)
apic_test_vector(vector, apic->regs + APIC_IRR);
}
+bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm)
+{
+ /*
+ * The default in-kernel I/O APIC emulates the 82093AA and does not
+ * implement an EOI register. Some guests (e.g. Windows with the
+ * Hyper-V role enabled) disable LAPIC EOI broadcast without checking
+ * the I/O APIC version, which can cause level-triggered interrupts to
+ * never be EOI'd.
+ *
+ * To avoid this, KVM must not advertise Suppress EOI Broadcast support
+ * when using the default in-kernel I/O APIC.
+ *
+ * Historically, in split IRQCHIP mode, KVM always advertised Suppress
+ * EOI Broadcast support but did not actually suppress EOIs, resulting
+ * in quirky behavior.
+ */
+ return !ioapic_in_kernel(kvm);
+}
+
+bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm)
+{
+ /*
+ * Returns true if KVM should honor the guest's request to suppress EOI
+ * broadcasts, i.e. actually implement Suppress EOI Broadcast.
+ *
+ * Historically, in split IRQCHIP mode, KVM ignored the suppress EOI
+ * broadcast bit set by the guest and broadcasts EOIs to the userspace
+ * I/O APIC. For In-kernel I/O APIC, the support itself is not
+ * advertised, but if bit was set by the guest, it was respected.
+ */
+ return ioapic_in_kernel(kvm);
+}
+
__read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu);
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_has_noapic_vcpu);
@@ -554,15 +587,9 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu)
v = APIC_VERSION | ((apic->nr_lvt_entries - 1) << 16);
- /*
- * KVM emulates 82093AA datasheet (with in-kernel IOAPIC implementation)
- * which doesn't have EOI register; Some buggy OSes (e.g. Windows with
- * Hyper-V role) disable EOI broadcast in lapic not checking for IOAPIC
- * version first and level-triggered interrupts never get EOIed in
- * 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);
}
@@ -1517,6 +1544,16 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
/* Request a KVM exit to inform the userspace IOAPIC. */
if (irqchip_split(apic->vcpu->kvm)) {
+ /*
+ * Don't exit to userspace 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).
+ */
+ if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) &&
+ kvm_lapic_respect_suppress_eoi_broadcast(apic->vcpu->kvm))
+ return;
+
apic->vcpu->arch.pending_ioapic_eoi = vector;
kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu);
return;
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 282b9b7da98c..fe2db0f1d190 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -231,6 +231,9 @@ static inline int kvm_lapic_latched_init(struct kvm_vcpu *vcpu)
bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector);
+bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm);
+bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm);
+
void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu);
void kvm_bitmap_or_dest_vcpus(struct kvm *kvm, struct kvm_lapic_irq *irq,
--
2.39.3On Mon, Dec 29, 2025, Khushit Shah wrote:
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 0ae7f913d782..2c24fd8d815f 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -105,6 +105,39 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector)
> apic_test_vector(vector, apic->regs + APIC_IRR);
> }
>
> +bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm)
This can be static, its only caller is kvm_apic_set_version().
> +{
> + /*
> + * The default in-kernel I/O APIC emulates the 82093AA and does not
> + * implement an EOI register. Some guests (e.g. Windows with the
> + * Hyper-V role enabled) disable LAPIC EOI broadcast without checking
> + * the I/O APIC version, which can cause level-triggered interrupts to
> + * never be EOI'd.
> + *
> + * To avoid this, KVM must not advertise Suppress EOI Broadcast support
> + * when using the default in-kernel I/O APIC.
> + *
> + * Historically, in split IRQCHIP mode, KVM always advertised Suppress
> + * EOI Broadcast support but did not actually suppress EOIs, resulting
> + * in quirky behavior.
> + */
> + return !ioapic_in_kernel(kvm);
> +}
> +
> +bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm)
I don't see any point in forcing every caller to check SPIV *and* this helper.
Just do:
bool kvm_lapic_suppress_eoi_broadcast(struct kvm_lapic *apic)
{
struct kvm *kvm = apic->vcpu->kvm;
if (!(kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI))
return false;
switch (kvm->arch.suppress_eoi_broadcast_mode) {
...
}
}
And then callers are much more readable, e.g. (spoiler alert if you haven't read
my other mail, which I haven't sent yet):
if (trigger_mode != IOAPIC_LEVEL_TRIG ||
kvm_lapic_suppress_eoi_broadcast(apic))
return;
and
/* Request a KVM exit to inform the userspace IOAPIC. */
if (irqchip_split(apic->vcpu->kvm)) {
/*
* Don't exit to userspace 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).
*/
if (kvm_lapic_suppress_eoi_broadcast(apic))
return;
apic->vcpu->arch.pending_ioapic_eoi = vector;
kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu);
return;
}
On Mon, 2025-12-29 at 11:17 +0000, Khushit Shah wrote: > Extract the suppress EOI broadcast (Directed EOI) logic into helper > functions and move the check from kvm_ioapic_update_eoi_one() to > kvm_ioapic_update_eoi() (required for a later patch). Prepare > kvm_ioapic_send_eoi() to honor Suppress EOI Broadcast in split IRQCHIP > mode. > > Introduce two helper functions: > - kvm_lapic_advertise_suppress_eoi_broadcast(): determines whether KVM > should advertise Suppress EOI Broadcast support to the guest > - kvm_lapic_respect_suppress_eoi_broadcast(): determines whether KVM should > honor the guest's request to suppress EOI broadcasts > > This refactoring prepares for I/O APIC version 0x20 support and userspace > control of suppress EOI broadcast behavior. > > Signed-off-by: Khushit Shah <khushit.shah@nutanix.com> Looks good to me, thanks for pushing this through to completion! Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Nit: Ideally I would would prefer to see an explicit 'no functional change intended' and a reference to commit 0bcc3fb95b97a.
> On 2 Jan 2026, at 9:53 PM, David Woodhouse <dwmw2@infradead.org> wrote: > > On Mon, 2025-12-29 at 11:17 +0000, Khushit Shah wrote: >> Extract the suppress EOI broadcast (Directed EOI) logic into helper >> functions and move the check from kvm_ioapic_update_eoi_one() to >> kvm_ioapic_update_eoi() (required for a later patch). Prepare >> kvm_ioapic_send_eoi() to honor Suppress EOI Broadcast in split IRQCHIP >> mode. >> >> Introduce two helper functions: >> - kvm_lapic_advertise_suppress_eoi_broadcast(): determines whether KVM >> should advertise Suppress EOI Broadcast support to the guest >> - kvm_lapic_respect_suppress_eoi_broadcast(): determines whether KVM should >> honor the guest's request to suppress EOI broadcasts >> >> This refactoring prepares for I/O APIC version 0x20 support and userspace >> control of suppress EOI broadcast behavior. >> >> Signed-off-by: Khushit Shah <khushit.shah@nutanix.com> > > Looks good to me, thanks for pushing this through to completion! > > > Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> > > Nit: Ideally I would would prefer to see an explicit 'no functional > change intended' and a reference to commit 0bcc3fb95b97a. I took another careful look at the refactor specifically through the “no functional change” lens. The legacy behavior with the in-kernel IRQCHIP can be summarized as: - Suppress EOI Broadcast (SEOIB) is not advertised to the guest. - If the guest nevertheless enables SEOIB, it is honored (already in un-s upported territory). - Even in that case, the legacy code still ends up calling kvm_notify_acked_irq() in kvm_ioapic_update_eoi_one(). With the refactor, kvm_notify_acked_irq() is no longer reached in this specific legacy scenario when the guest enables SEOIB despite it not being advertised. I believe this is acceptable, as the guest is relying on an unadvertised feature. For non-QUIRKED configurations, the behavior is also correct: - When SEOIB is ENABLED, kvm_notify_acked_irq() is called on EOIR write, when enabled by guest. - When SEOIB is DISABLED, kvm_notify_acked_irq() is called on EOI broadcast. I would appreciate others chiming in if they see a reason to preserve the legacy ack behavior even in the unsupported case.
On Mon, Jan 12, 2026, Khushit Shah wrote:
> > On 2 Jan 2026, at 9:53 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > On Mon, 2025-12-29 at 11:17 +0000, Khushit Shah wrote:
> >> Extract the suppress EOI broadcast (Directed EOI) logic into helper
> >> functions and move the check from kvm_ioapic_update_eoi_one() to
> >> kvm_ioapic_update_eoi() (required for a later patch). Prepare
> >> kvm_ioapic_send_eoi() to honor Suppress EOI Broadcast in split IRQCHIP
> >> mode.
> >>
> >> Introduce two helper functions:
> >> - kvm_lapic_advertise_suppress_eoi_broadcast(): determines whether KVM
> >> should advertise Suppress EOI Broadcast support to the guest
> >> - kvm_lapic_respect_suppress_eoi_broadcast(): determines whether KVM should
> >> honor the guest's request to suppress EOI broadcasts
> >>
> >> This refactoring prepares for I/O APIC version 0x20 support and userspace
> >> control of suppress EOI broadcast behavior.
> >>
> >> Signed-off-by: Khushit Shah <khushit.shah@nutanix.com>
> >
> > Looks good to me, thanks for pushing this through to completion!
> >
> >
> > Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Nit: Ideally I would would prefer to see an explicit 'no functional
> > change intended' and a reference to commit 0bcc3fb95b97a.
>
>
> I took another careful look at the refactor specifically through the
> “no functional change” lens.
>
> The legacy behavior with the in-kernel IRQCHIP can be summarized as:
> - Suppress EOI Broadcast (SEOIB) is not advertised to the guest.
> - If the guest nevertheless enables SEOIB, it is honored (already in un-s
> upported territory).
No, KVM will drop the attempt to enable SEOIB, because APIC_LVR won't have
APIC_LVR_DIRECTED_EOI (KVM fully controls the version info, e.g. calls
kvm_apic_set_version() even in kvm_apic_set_state() after copying user state).
case APIC_SPIV: {
u32 mask = 0x3ff;
if (kvm_lapic_get_reg(apic, APIC_LVR) & APIC_LVR_DIRECTED_EOI)
mask |= APIC_SPIV_DIRECTED_EOI;
apic_set_spiv(apic, val & mask);
if (!(val & APIC_SPIV_APIC_ENABLED)) {
int i;
for (i = 0; i < apic->nr_lvt_entries; i++) {
kvm_lapic_set_reg(apic, APIC_LVTx(i),
kvm_lapic_get_reg(apic, APIC_LVTx(i)) | APIC_LVT_MASKED);
}
apic_update_lvtt(apic);
atomic_set(&apic->lapic_timer.pending, 0);
}
break;
}
It _is_ possible for the virtual APIC to end up with the bit set, because KVM
doesn't sanitize APIC_SPIV during kvm_apic_set_state().
> - Even in that case, the legacy code still ends up calling
> kvm_notify_acked_irq() in kvm_ioapic_update_eoi_one().
>
> With the refactor, kvm_notify_acked_irq() is no longer reached in this
> specific legacy scenario when the guest enables SEOIB despite it not
> being advertised. I believe this is acceptable, as the guest is relying
> on an unadvertised feature.
Except that it needs to work when it's re-enabled in a few patches. And as per
commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI") and
https://bugzilla.kernel.org/show_bug.cgi?id=82211, allegedly KVM needs to notify
listeners in this case.
Given that KVM didn't actually implement Directed EOI in the in-kernel I/O APIC,
it's certainly debatable as to whether or not that still holds true, i.e. it may
have been a misdiagnosed root cause. But I have zero interest in finding out
the hard way, especially since the in-kernel I/O APIC is slowly being deprecated,
and _especially_ not in patches that will be Cc'd stable.
So while I agree it would be nice to simultaneously enable the in-kernel I/O APIC,
I want to prioritize landing the fix for split IRQCHIP. And if we're clever,
enabling in-kernel I/O APIC support in the future shouldn't require any new uAPI,
since we can document the limitation and not advertise
KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST in KVM_CAP_X2APIC_API when run on a VM
without a split IRQCHIP. Then if support is ever added broadly, we can drop the
relevant code that requires irqchip_split() and update the documentation to say
that userspace need to query KVM_CAP_X2APIC_API on a VM fd to determine whether
or not the flag is supported for an in-kernel I/O APIC.
If someone has a strong need and use case for supporting Supress EOI Broadcast for
an in-kernel I/O APIC, then they can have the honor of proving that things like
Windows and Xen play nice with KVM's implementation. And they can do that on top.
Compile tested only, but this is what I'd like to go with for now (in a single
patch, because IMO isolating the refactoring isn't a net positive without patch 2/3).
--
From: Khushit Shah <khushit.shah@nutanix.com>
Date: Mon, 29 Dec 2025 11:17:06 +0000
Subject: [PATCH] KVM: x86: Add x2APIC "features" to control EOI broadcast
suppression
Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support
for Suppress EOI Broadcasts when using a split IRQCHIP (I/O APIC emulated
by userspace), which KVM completely mishandles. When x2APIC support was
first added, KVM incorrectly advertised and "enabled" Suppress EOI
Broadcast, without fully supporting the I/O APIC side of the equation,
i.e. without adding directed EOI to KVM's in-kernel I/O APIC.
That flaw was carried over to split IRQCHIP support, i.e. KVM advertised
support for Suppress EOI Broadcasts irrespective of whether or not the
userspace I/O APIC implementation supported directed EOIs. Even worse,
KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without
support for directed EOI came to rely on the "spurious" broadcasts.
KVM "fixed" the in-kernel I/O APIC implementation by completely disabling
support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic:
stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but
didn't do anything to remedy userspace I/O APIC implementations.
KVM's bogus handling of Suppress EOI Broadcast is problematic when the
guest relies on interrupts being masked in the I/O APIC until well after
the initial local APIC EOI. E.g. Windows with Credential Guard enabled
handles interrupts in the following order:
1. Interrupt for L2 arrives.
2. L1 APIC EOIs the interrupt.
3. L1 resumes L2 and injects the interrupt.
4. L2 EOIs after servicing.
5. L1 performs the I/O APIC EOI.
Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt
storm, e.g. if the IRQ line is still asserted and userspace reacts to the
EOI by re-injecting the IRQ, because the guest doesn't de-assert the line
until step #4, and doesn't expect the interrupt to be re-enabled until
step #5.
Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way
of knowing if the userspace I/O APIC supports directed EOIs, i.e.
suppressing EOI broadcasts would result in interrupts being stuck masked
in the userspace I/O APIC due to step #5 being ignored by userspace. And
fully disabling support for Suppress EOI Broadcast is also undesirable, as
picking up the fix would require a guest reboot, *and* more importantly
would change the virtual CPU model exposed to the guest without any buy-in
from userspace.
Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and
KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to
explicitly enable or disable support for Suppress EOI Broadcasts. This
gives userspace control over the virtual CPU model exposed to the guest,
as KVM should never have enabled support for Suppress EOI Broadcast without
userspace opt-in. Not setting either flag will result in legacy quirky
behavior for backward compatibility.
Disallow fully enabling SUPPRESS_EOI_BROADCAST when using an in-kernel
I/O APIC, as KVM's history/support is just as tragic. E.g. it's not clear
that commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI")
was entirely correct, i.e. it may have simply papered over the lack of
Directed EOI emulation in the I/O APIC.
Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's
APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI
is to support Directed EOI (KVM's name) irrespective of guest CPU vendor.
Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs")
Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com
Cc: stable@vger.kernel.org
Suggested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Khushit Shah <khushit.shah@nutanix.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
Documentation/virt/kvm/api.rst | 28 +++++++++++-
arch/x86/include/asm/kvm_host.h | 7 +++
arch/x86/include/uapi/asm/kvm.h | 6 ++-
arch/x86/kvm/ioapic.c | 2 +-
arch/x86/kvm/lapic.c | 76 +++++++++++++++++++++++++++++----
arch/x86/kvm/lapic.h | 2 +
arch/x86/kvm/x86.c | 21 ++++++++-
7 files changed, 127 insertions(+), 15 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 01a3abef8abb..f1f1d2e5dc7c 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7835,8 +7835,10 @@ Will return -EBUSY if a VCPU has already been created.
Valid feature flags in args[0] are::
- #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
- #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
+ #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
+ #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
+ #define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (1ULL << 2)
+ #define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3)
Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of
KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC,
@@ -7849,6 +7851,28 @@ as a broadcast even in x2APIC mode in order to support physical x2APIC
without interrupt remapping. This is undesirable in logical mode,
where 0xff represents CPUs 0-7 in cluster 0.
+Setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST instructs KVM to enable
+Suppress EOI Broadcasts. KVM will advertise support for Suppress EOI
+Broadcast to the guest and suppress LAPIC EOI broadcasts when the guest
+sets the Suppress EOI Broadcast bit in the SPIV register. This flag is
+supported only when using a split IRQCHIP.
+
+Setting KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST disables support for
+Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise
+support to the guest.
+
+Modern VMMs should either enable KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST
+or KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST. If not, legacy quirky
+behavior will be used by KVM: in split IRQCHIP mode, KVM will advertise
+support for Suppress EOI Broadcasts but not actually suppress EOI
+broadcasts; for in-kernel IRQCHIP mode, KVM will not advertise support for
+Suppress EOI Broadcasts.
+
+Setting both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and
+KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST will fail with an EINVAL error,
+as will setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST without a split
+IRCHIP.
+
7.8 KVM_CAP_S390_USER_INSTR0
----------------------------
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index ecd4019b84b7..125bd9a4b807 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1238,6 +1238,12 @@ enum kvm_irqchip_mode {
KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */
};
+enum kvm_suppress_eoi_broadcast_mode {
+ KVM_SUPPRESS_EOI_BROADCAST_QUIRKED, /* Legacy behavior */
+ KVM_SUPPRESS_EOI_BROADCAST_ENABLED, /* Enable Suppress EOI broadcast */
+ KVM_SUPPRESS_EOI_BROADCAST_DISABLED /* Disable Suppress EOI broadcast */
+};
+
struct kvm_x86_msr_filter {
u8 count;
bool default_allow:1;
@@ -1487,6 +1493,7 @@ struct kvm_arch {
bool x2apic_format;
bool x2apic_broadcast_quirk_disabled;
+ enum kvm_suppress_eoi_broadcast_mode suppress_eoi_broadcast_mode;
bool has_mapped_host_mmio;
bool guest_can_read_msr_platform_info;
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 7ceff6583652..1b0ad5440b99 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -914,8 +914,10 @@ struct kvm_sev_snp_launch_finish {
__u64 pad1[4];
};
-#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
-#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
+#define KVM_X2APIC_API_USE_32BIT_IDS (_BITULL(0))
+#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (_BITULL(1))
+#define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (_BITULL(2))
+#define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (_BITULL(3))
struct kvm_hyperv_eventfd {
__u32 conn_id;
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 9a99d01b111c..a38a8e2ac70b 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -555,7 +555,7 @@ static void kvm_ioapic_update_eoi_one(struct kvm_vcpu *vcpu,
spin_lock(&ioapic->lock);
if (trigger_mode != IOAPIC_LEVEL_TRIG ||
- kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI)
+ kvm_lapic_suppress_eoi_broadcast(apic))
return;
ent->fields.remote_irr = 0;
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 78c39341b2a5..c175a021e1a9 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -105,6 +105,63 @@ 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)
+{
+ switch (kvm->arch.suppress_eoi_broadcast_mode) {
+ case KVM_SUPPRESS_EOI_BROADCAST_ENABLED:
+ return true;
+ case KVM_SUPPRESS_EOI_BROADCAST_DISABLED:
+ return false;
+ case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED:
+ /*
+ * The default in-kernel I/O APIC emulates the 82093AA and does not
+ * implement an EOI register. Some guests (e.g. Windows with the
+ * Hyper-V role enabled) disable LAPIC EOI broadcast without
+ * checking the I/O APIC version, which can cause level-triggered
+ * interrupts to never be EOI'd.
+ *
+ * To avoid this, KVM doesn't advertise Suppress EOI Broadcast
+ * support when using the default in-kernel I/O APIC.
+ *
+ * Historically, in split IRQCHIP mode, KVM always advertised
+ * Suppress EOI Broadcast support but did not actually suppress
+ * EOIs, resulting in quirky behavior.
+ */
+ return !ioapic_in_kernel(kvm);
+ default:
+ WARN_ON_ONCE(1);
+ return false;
+ }
+}
+
+bool kvm_lapic_suppress_eoi_broadcast(struct kvm_lapic *apic)
+{
+ struct kvm *kvm = apic->vcpu->kvm;
+
+ if (!(kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI))
+ return false;
+
+ switch (kvm->arch.suppress_eoi_broadcast_mode) {
+ case KVM_SUPPRESS_EOI_BROADCAST_ENABLED:
+ return true;
+ case KVM_SUPPRESS_EOI_BROADCAST_DISABLED:
+ return false;
+ case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED:
+ /*
+ * Historically, in split IRQCHIP mode, KVM ignored the suppress
+ * EOI broadcast bit set by the guest and broadcasts EOIs to the
+ * userspace I/O APIC. For In-kernel I/O APIC, the support itself
+ * is not advertised, can only be enabled KVM_SET_APIC_STATE, and
+ * and KVM's I/O APIC doesn't emulate Directed EOIs; but if the
+ * feature is enabled, it is respected (with odd behavior).
+ */
+ return ioapic_in_kernel(kvm);
+ default:
+ WARN_ON_ONCE(1);
+ return false;
+ }
+}
+
__read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu);
EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_has_noapic_vcpu);
@@ -554,15 +611,9 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu)
v = APIC_VERSION | ((apic->nr_lvt_entries - 1) << 16);
- /*
- * KVM emulates 82093AA datasheet (with in-kernel IOAPIC implementation)
- * which doesn't have EOI register; Some buggy OSes (e.g. Windows with
- * Hyper-V role) disable EOI broadcast in lapic not checking for IOAPIC
- * version first and level-triggered interrupts never get EOIed in
- * 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);
}
@@ -1517,6 +1568,15 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
/* Request a KVM exit to inform the userspace IOAPIC. */
if (irqchip_split(apic->vcpu->kvm)) {
+ /*
+ * Don't exit to userspace 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).
+ */
+ if (kvm_lapic_suppress_eoi_broadcast(apic))
+ return;
+
apic->vcpu->arch.pending_ioapic_eoi = vector;
kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu);
return;
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 71c80fa020e0..cf8aed8c95ea 100644
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -239,6 +239,8 @@ static inline int kvm_lapic_latched_init(struct kvm_vcpu *vcpu)
bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector);
+bool kvm_lapic_suppress_eoi_broadcast(struct kvm_lapic *apic);
+
void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu);
void kvm_bitmap_or_dest_vcpus(struct kvm *kvm, struct kvm_lapic_irq *irq,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3d4e07f9cff5..82d893d262fa 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -121,8 +121,10 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE);
#define KVM_CAP_PMU_VALID_MASK KVM_PMU_CAP_DISABLE
-#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \
- KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK)
+#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \
+ KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK | \
+ KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST | \
+ KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)
static void update_cr8_intercept(struct kvm_vcpu *vcpu);
static void process_nmi(struct kvm_vcpu *vcpu);
@@ -4943,6 +4945,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_X2APIC_API:
r = KVM_X2APIC_API_VALID_FLAGS;
+ if (kvm && !irqchip_split(kvm))
+ r &= ~KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST;
break;
case KVM_CAP_NESTED_STATE:
r = kvm_x86_ops.nested_ops->get_state ?
@@ -6751,11 +6755,24 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
if (cap->args[0] & ~KVM_X2APIC_API_VALID_FLAGS)
break;
+ if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) &&
+ (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST))
+ break;
+
+ if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) &&
+ !irqchip_split(kvm))
+ break;
+
if (cap->args[0] & KVM_X2APIC_API_USE_32BIT_IDS)
kvm->arch.x2apic_format = true;
if (cap->args[0] & KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK)
kvm->arch.x2apic_broadcast_quirk_disabled = true;
+ if (cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST)
+ kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_ENABLED;
+ if (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)
+ kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_DISABLED;
+
r = 0;
break;
case KVM_CAP_X86_DISABLE_EXITS:
base-commit: f62b64b970570c92fe22503b0cdc65be7ce7fc7c
--
On Tue, 2026-01-13 at 16:10 -0800, Sean Christopherson wrote:
> Except that it needs to work when it's re-enabled in a few patches. And as per
> commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI") and
> https://bugzilla.kernel.org/show_bug.cgi?id=82211, allegedly KVM needs to notify
> listeners in this case.
But KVM *will* notify listeners, surely? When the guest issues the EOI
via the I/O APIC EOIR register.
For that commit to have made any difference, Xen *has* to have been
buggy, enabling directed EOI in the local APIC despite the I/O APIC not
having the required support. Thus interrupts never got EOI'd at all,
and sure, the notifiers didn't get called.
> Given that KVM didn't actually implement Directed EOI in the in-kernel I/O APIC,
> it's certainly debatable as to whether or not that still holds true, i.e. it may
> have been a misdiagnosed root cause. But I have zero interest in finding out
> the hard way, especially since the in-kernel I/O APIC is slowly being deprecated,
> and _especially_ not in patches that will be Cc'd stable.
Isn't that *exactly* the issue we knew we were resolving properly by
implementing the EOIR in the I/O APIC?
We should test, sure. But I don't think the existence of that commit
should make us throw our hands up in the air and be too scared of just
fixing it properly.
> So while I agree it would be nice to simultaneously enable the in-kernel I/O APIC,
> I want to prioritize landing the fix for split IRQCHIP. And if we're clever,
> enabling in-kernel I/O APIC support in the future shouldn't require any new uAPI,
> since we can document the limitation and not advertise
> KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST in KVM_CAP_X2APIC_API when run on a VM
> without a split IRQCHIP. Then if support is ever added broadly, we can drop the
> relevant code that requires irqchip_split() and update the documentation to say
> that userspace need to query KVM_CAP_X2APIC_API on a VM fd to determine whether
> or not the flag is supported for an in-kernel I/O APIC.
>
> If someone has a strong need and use case for supporting Supress EOI Broadcast for
> an in-kernel I/O APIC, then they can have the honor of proving that things like
> Windows and Xen play nice with KVM's implementation. And they can do that on top.
>
> Compile tested only, but this is what I'd like to go with for now (in a single
> patch, because IMO isolating the refactoring isn't a net positive without patch 2/3).
I dislike this. It's just another wart. And it looks like userspace can
still check the cap and set KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST,
and *then* add the in-kernel I/O APIC afterwards?
If you're concerned about what to backport to stable, then arguably
it's *only* KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST which should be
backported, as that's the bug, and _ENABLE_ is a new feature?
> On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> But KVM *will* notify listeners, surely? When the guest issues the EOI
> via the I/O APIC EOIR register.
>
> For that commit to have made any difference, Xen *has* to have been
> buggy, enabling directed EOI in the local APIC despite the I/O APIC not
> having the required support. Thus interrupts never got EOI'd at all,
> and sure, the notifiers didn't get called.
You are describing
0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use”)
Since then I guess this issue should have been fixed?! As
c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI”) was much earlier.
> On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> If you're concerned about what to backport to stable, then arguably
> it's *only* KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST which should be
> backported, as that's the bug, and _ENABLE_ is a new feature?
I think neither DISABLE or ENABLE is a new feature at least for split IRQCHIP.
It’s just giving a way to user-space to fix a bug in a way they like, because that’s how
it should have been from the beginning.
On Fri, Jan 16, 2026, Khushit Shah wrote:
> > On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > But KVM *will* notify listeners, surely? When the guest issues the EOI
> > via the I/O APIC EOIR register.
> >
> > For that commit to have made any difference, Xen *has* to have been
> > buggy, enabling directed EOI in the local APIC despite the I/O APIC not
> > having the required support. Thus interrupts never got EOI'd at all,
> > and sure, the notifiers didn't get called.
Oh, I 100% agree there were bugs aplenty on both sides, but that's exactly why I
don't want to add support for the in-kernel I/O APIC without a strong reason for
doing so.
> You are describing
> 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use”)
> Since then I guess this issue should have been fixed?! As
> c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI”) was much earlier.
>
> > On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > If you're concerned about what to backport to stable, then arguably
> > it's *only* KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST which should be
> > backported, as that's the bug, and _ENABLE_ is a new feature?
>
> I think neither DISABLE or ENABLE is a new feature at least for split
> IRQCHIP. It’s just giving a way to user-space to fix a bug in a way they
> like, because that’s how it should have been from the beginning.
Ya. I don't see ENABLE (for split IRQCHIP) as a new feature, because it's the
only way for userspace to fix its setups without changing the virtual CPU model
exposed to the guest.
For better or worse, the aforementioned commit 0bcc3fb95b97 ("KVM: lapic: stop
advertising DIRECTED_EOI when in-kernel IOAPIC is in use”) already clobbered the
virtual model when using an in-kernel I/O APIC. Even though KVM (AFAIK) got away
with the switcheroo then, I am strongly opposed to _KVM_ changing the virtual CPU
model. I.e. I want to give userspace the ability to choose how to address the
issue, because only userspace (or rather, the platform owner) knows whether or
not its I/O APIC implementation plays nice with ENABLE, whether it's risker to
continue with QUIRK vs. DISABLE, etc.
Tested the patch and works as expected. Sent v6.
> On 14 Jan 2026, at 5:40 AM, Sean Christopherson <seanjc@google.com> wrote:
>
> case APIC_SPIV: {
> u32 mask = 0x3ff;
> if (kvm_lapic_get_reg(apic, APIC_LVR) & APIC_LVR_DIRECTED_EOI)
> mask |= APIC_SPIV_DIRECTED_EOI;
> apic_set_spiv(apic, val & mask);
> if (!(val & APIC_SPIV_APIC_ENABLED)) {
> int i;
>
> for (i = 0; i < apic->nr_lvt_entries; i++) {
> kvm_lapic_set_reg(apic, APIC_LVTx(i),
> kvm_lapic_get_reg(apic, APIC_LVTx(i)) | APIC_LVT_MASKED);
> }
> apic_update_lvtt(apic);
> atomic_set(&apic->lapic_timer.pending, 0);
>
> }
> break;
> }
>
> It _is_ possible for the virtual APIC to end up with the bit set, because KVM
> doesn't sanitize APIC_SPIV during kvm_apic_set_state().
Ohh Wow! Okay.
> On 14 Jan 2026, at 5:40 AM, Sean Christopherson <seanjc@google.com> wrote:
>
> Except that it needs to work when it's re-enabled in a few patches. And as per
> commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI") and
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D82211&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=PGWMyignA0NiDmTlyP7vOTHozBws_VN86yrVmSMkBp0&m=3a8aRAaT-5-y7XGNZDSigpCoMKWgZMPHgKMf0pNKs-BEnjmuhtg8NxX9-jSx6CTp&s=qRth9VSXr8AqIx-tfKzLf8j4Fks5TtSdUMHhre4cgAo&e= , allegedly KVM needs to notify
> listeners in this case.
>
> Given that KVM didn't actually implement Directed EOI in the in-kernel I/O APIC,
> it's certainly debatable as to whether or not that still holds true, i.e. it may
> have been a misdiagnosed root cause. But I have zero interest in finding out
> the hard way, especially since the in-kernel I/O APIC is slowly being deprecated,
> and _especially_ not in patches that will be Cc'd stable.
>
> So while I agree it would be nice to simultaneously enable the in-kernel I/O APIC,
> I want to prioritize landing the fix for split IRQCHIP. And if we're clever,
> enabling in-kernel I/O APIC support in the future shouldn't require any new uAPI,
> since we can document the limitation and not advertise
> KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST in KVM_CAP_X2APIC_API when run on a VM
> without a split IRQCHIP. Then if support is ever added broadly, we can drop the
> relevant code that requires irqchip_split() and update the documentation to say
> that userspace need to query KVM_CAP_X2APIC_API on a VM fd to determine whether
> or not the flag is supported for an in-kernel I/O APIC.
>
> If someone has a strong need and use case for supporting Supress EOI Broadcast for
> an in-kernel I/O APIC, then they can have the honor of proving that things like
> Windows and Xen play nice with KVM's implementation. And they can do that on top.
I agree on not finding it the hard way. I am okay with prioritising fix for split IRQCHIP.
> On 14 Jan 2026, at 5:40 AM, Sean Christopherson <seanjc@google.com> wrote:
>
> --
> From: Khushit Shah <khushit.shah@nutanix.com>
> Date: Mon, 29 Dec 2025 11:17:06 +0000
> Subject: [PATCH] KVM: x86: Add x2APIC "features" to control EOI broadcast
> suppression
>
> Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support
> for Suppress EOI Broadcasts when using a split IRQCHIP (I/O APIC emulated
> by userspace), which KVM completely mishandles. When x2APIC support was
> first added, KVM incorrectly advertised and "enabled" Suppress EOI
> Broadcast, without fully supporting the I/O APIC side of the equation,
> i.e. without adding directed EOI to KVM's in-kernel I/O APIC.
>
> That flaw was carried over to split IRQCHIP support, i.e. KVM advertised
> support for Suppress EOI Broadcasts irrespective of whether or not the
> userspace I/O APIC implementation supported directed EOIs. Even worse,
> KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without
> support for directed EOI came to rely on the "spurious" broadcasts.
>
> KVM "fixed" the in-kernel I/O APIC implementation by completely disabling
> support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic:
> stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but
> didn't do anything to remedy userspace I/O APIC implementations.
>
> KVM's bogus handling of Suppress EOI Broadcast is problematic when the
> guest relies on interrupts being masked in the I/O APIC until well after
> the initial local APIC EOI. E.g. Windows with Credential Guard enabled
> handles interrupts in the following order:
> 1. Interrupt for L2 arrives.
> 2. L1 APIC EOIs the interrupt.
> 3. L1 resumes L2 and injects the interrupt.
> 4. L2 EOIs after servicing.
> 5. L1 performs the I/O APIC EOI.
>
> Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt
> storm, e.g. if the IRQ line is still asserted and userspace reacts to the
> EOI by re-injecting the IRQ, because the guest doesn't de-assert the line
> until step #4, and doesn't expect the interrupt to be re-enabled until
> step #5.
>
> Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way
> of knowing if the userspace I/O APIC supports directed EOIs, i.e.
> suppressing EOI broadcasts would result in interrupts being stuck masked
> in the userspace I/O APIC due to step #5 being ignored by userspace. And
> fully disabling support for Suppress EOI Broadcast is also undesirable, as
> picking up the fix would require a guest reboot, *and* more importantly
> would change the virtual CPU model exposed to the guest without any buy-in
> from userspace.
>
> Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and
> KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to
> explicitly enable or disable support for Suppress EOI Broadcasts. This
> gives userspace control over the virtual CPU model exposed to the guest,
> as KVM should never have enabled support for Suppress EOI Broadcast without
> userspace opt-in. Not setting either flag will result in legacy quirky
> behavior for backward compatibility.
>
> Disallow fully enabling SUPPRESS_EOI_BROADCAST when using an in-kernel
> I/O APIC, as KVM's history/support is just as tragic. E.g. it's not clear
> that commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI")
> was entirely correct, i.e. it may have simply papered over the lack of
> Directed EOI emulation in the I/O APIC.
>
> Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's
> APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI
> is to support Directed EOI (KVM's name) irrespective of guest CPU vendor.
>
> Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs")
> Closes: https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_kvm_7D497EF1-2D607D-2D4D37-2D98E7-2DDAF95F099342-40nutanix.com&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=PGWMyignA0NiDmTlyP7vOTHozBws_VN86yrVmSMkBp0&m=3a8aRAaT-5-y7XGNZDSigpCoMKWgZMPHgKMf0pNKs-BEnjmuhtg8NxX9-jSx6CTp&s=KnIT5Yo-kg0bFDhJahB2sRZX445TmPKS4mmCSM0vhqo&e=
> Cc: stable@vger.kernel.org
> Suggested-by: David Woodhouse <dwmw2@infradead.org>
> Signed-off-by: Khushit Shah <khushit.shah@nutanix.com>
> Co-developed-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> Documentation/virt/kvm/api.rst | 28 +++++++++++-
> arch/x86/include/asm/kvm_host.h | 7 +++
> arch/x86/include/uapi/asm/kvm.h | 6 ++-
> arch/x86/kvm/ioapic.c | 2 +-
> arch/x86/kvm/lapic.c | 76 +++++++++++++++++++++++++++++----
> arch/x86/kvm/lapic.h | 2 +
> arch/x86/kvm/x86.c | 21 ++++++++-
> 7 files changed, 127 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 01a3abef8abb..f1f1d2e5dc7c 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7835,8 +7835,10 @@ Will return -EBUSY if a VCPU has already been created.
>
> Valid feature flags in args[0] are::
>
> - #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
> - #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
> + #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
> + #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
> + #define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (1ULL << 2)
> + #define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3)
>
> Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of
> KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC,
> @@ -7849,6 +7851,28 @@ as a broadcast even in x2APIC mode in order to support physical x2APIC
> without interrupt remapping. This is undesirable in logical mode,
> where 0xff represents CPUs 0-7 in cluster 0.
>
> +Setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST instructs KVM to enable
> +Suppress EOI Broadcasts. KVM will advertise support for Suppress EOI
> +Broadcast to the guest and suppress LAPIC EOI broadcasts when the guest
> +sets the Suppress EOI Broadcast bit in the SPIV register. This flag is
> +supported only when using a split IRQCHIP.
> +
> +Setting KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST disables support for
> +Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise
> +support to the guest.
> +
> +Modern VMMs should either enable KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST
> +or KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST. If not, legacy quirky
> +behavior will be used by KVM: in split IRQCHIP mode, KVM will advertise
> +support for Suppress EOI Broadcasts but not actually suppress EOI
> +broadcasts; for in-kernel IRQCHIP mode, KVM will not advertise support for
> +Suppress EOI Broadcasts.
> +
> +Setting both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and
> +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST will fail with an EINVAL error,
> +as will setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST without a split
> +IRCHIP.
> +
> 7.8 KVM_CAP_S390_USER_INSTR0
> ----------------------------
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index ecd4019b84b7..125bd9a4b807 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1238,6 +1238,12 @@ enum kvm_irqchip_mode {
> KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */
> };
>
> +enum kvm_suppress_eoi_broadcast_mode {
> + KVM_SUPPRESS_EOI_BROADCAST_QUIRKED, /* Legacy behavior */
> + KVM_SUPPRESS_EOI_BROADCAST_ENABLED, /* Enable Suppress EOI broadcast */
> + KVM_SUPPRESS_EOI_BROADCAST_DISABLED /* Disable Suppress EOI broadcast */
> +};
> +
> struct kvm_x86_msr_filter {
> u8 count;
> bool default_allow:1;
> @@ -1487,6 +1493,7 @@ struct kvm_arch {
>
> bool x2apic_format;
> bool x2apic_broadcast_quirk_disabled;
> + enum kvm_suppress_eoi_broadcast_mode suppress_eoi_broadcast_mode;
>
> bool has_mapped_host_mmio;
> bool guest_can_read_msr_platform_info;
> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> index 7ceff6583652..1b0ad5440b99 100644
> --- a/arch/x86/include/uapi/asm/kvm.h
> +++ b/arch/x86/include/uapi/asm/kvm.h
> @@ -914,8 +914,10 @@ struct kvm_sev_snp_launch_finish {
> __u64 pad1[4];
> };
>
> -#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
> -#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
> +#define KVM_X2APIC_API_USE_32BIT_IDS (_BITULL(0))
> +#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (_BITULL(1))
> +#define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (_BITULL(2))
> +#define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (_BITULL(3))
>
> struct kvm_hyperv_eventfd {
> __u32 conn_id;
> diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
> index 9a99d01b111c..a38a8e2ac70b 100644
> --- a/arch/x86/kvm/ioapic.c
> +++ b/arch/x86/kvm/ioapic.c
> @@ -555,7 +555,7 @@ static void kvm_ioapic_update_eoi_one(struct kvm_vcpu *vcpu,
> spin_lock(&ioapic->lock);
>
> if (trigger_mode != IOAPIC_LEVEL_TRIG ||
> - kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI)
> + kvm_lapic_suppress_eoi_broadcast(apic))
> return;
>
> ent->fields.remote_irr = 0;
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 78c39341b2a5..c175a021e1a9 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -105,6 +105,63 @@ 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)
> +{
> + switch (kvm->arch.suppress_eoi_broadcast_mode) {
> + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED:
> + return true;
> + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED:
> + return false;
> + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED:
> + /*
> + * The default in-kernel I/O APIC emulates the 82093AA and does not
> + * implement an EOI register. Some guests (e.g. Windows with the
> + * Hyper-V role enabled) disable LAPIC EOI broadcast without
> + * checking the I/O APIC version, which can cause level-triggered
> + * interrupts to never be EOI'd.
> + *
> + * To avoid this, KVM doesn't advertise Suppress EOI Broadcast
> + * support when using the default in-kernel I/O APIC.
> + *
> + * Historically, in split IRQCHIP mode, KVM always advertised
> + * Suppress EOI Broadcast support but did not actually suppress
> + * EOIs, resulting in quirky behavior.
> + */
> + return !ioapic_in_kernel(kvm);
> + default:
> + WARN_ON_ONCE(1);
> + return false;
> + }
> +}
> +
> +bool kvm_lapic_suppress_eoi_broadcast(struct kvm_lapic *apic)
> +{
> + struct kvm *kvm = apic->vcpu->kvm;
> +
> + if (!(kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI))
> + return false;
> +
> + switch (kvm->arch.suppress_eoi_broadcast_mode) {
> + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED:
> + return true;
> + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED:
> + return false;
> + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED:
> + /*
> + * Historically, in split IRQCHIP mode, KVM ignored the suppress
> + * EOI broadcast bit set by the guest and broadcasts EOIs to the
> + * userspace I/O APIC. For In-kernel I/O APIC, the support itself
> + * is not advertised, can only be enabled KVM_SET_APIC_STATE, and
> + * and KVM's I/O APIC doesn't emulate Directed EOIs; but if the
> + * feature is enabled, it is respected (with odd behavior).
> + */
> + return ioapic_in_kernel(kvm);
> + default:
> + WARN_ON_ONCE(1);
> + return false;
> + }
> +}
> +
> __read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu);
> EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_has_noapic_vcpu);
>
> @@ -554,15 +611,9 @@ void kvm_apic_set_version(struct kvm_vcpu *vcpu)
>
> v = APIC_VERSION | ((apic->nr_lvt_entries - 1) << 16);
>
> - /*
> - * KVM emulates 82093AA datasheet (with in-kernel IOAPIC implementation)
> - * which doesn't have EOI register; Some buggy OSes (e.g. Windows with
> - * Hyper-V role) disable EOI broadcast in lapic not checking for IOAPIC
> - * version first and level-triggered interrupts never get EOIed in
> - * 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);
> }
> @@ -1517,6 +1568,15 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
>
> /* Request a KVM exit to inform the userspace IOAPIC. */
> if (irqchip_split(apic->vcpu->kvm)) {
> + /*
> + * Don't exit to userspace 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).
> + */
> + if (kvm_lapic_suppress_eoi_broadcast(apic))
> + return;
> +
> apic->vcpu->arch.pending_ioapic_eoi = vector;
> kvm_make_request(KVM_REQ_IOAPIC_EOI_EXIT, apic->vcpu);
> return;
> diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
> index 71c80fa020e0..cf8aed8c95ea 100644
> --- a/arch/x86/kvm/lapic.h
> +++ b/arch/x86/kvm/lapic.h
> @@ -239,6 +239,8 @@ static inline int kvm_lapic_latched_init(struct kvm_vcpu *vcpu)
>
> bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector);
>
> +bool kvm_lapic_suppress_eoi_broadcast(struct kvm_lapic *apic);
> +
> void kvm_wait_lapic_expire(struct kvm_vcpu *vcpu);
>
> void kvm_bitmap_or_dest_vcpus(struct kvm *kvm, struct kvm_lapic_irq *irq,
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 3d4e07f9cff5..82d893d262fa 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -121,8 +121,10 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE);
>
> #define KVM_CAP_PMU_VALID_MASK KVM_PMU_CAP_DISABLE
>
> -#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \
> - KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK)
> +#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \
> + KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK | \
> + KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST | \
> + KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)
>
> static void update_cr8_intercept(struct kvm_vcpu *vcpu);
> static void process_nmi(struct kvm_vcpu *vcpu);
> @@ -4943,6 +4945,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> break;
> case KVM_CAP_X2APIC_API:
> r = KVM_X2APIC_API_VALID_FLAGS;
> + if (kvm && !irqchip_split(kvm))
> + r &= ~KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST;
> break;
> case KVM_CAP_NESTED_STATE:
> r = kvm_x86_ops.nested_ops->get_state ?
> @@ -6751,11 +6755,24 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> if (cap->args[0] & ~KVM_X2APIC_API_VALID_FLAGS)
> break;
>
> + if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) &&
> + (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST))
> + break;
> +
> + if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) &&
> + !irqchip_split(kvm))
> + break;
> +
> if (cap->args[0] & KVM_X2APIC_API_USE_32BIT_IDS)
> kvm->arch.x2apic_format = true;
> if (cap->args[0] & KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK)
> kvm->arch.x2apic_broadcast_quirk_disabled = true;
>
> + if (cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST)
> + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_ENABLED;
> + if (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)
> + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_DISABLED;
> +
> r = 0;
> break;
> case KVM_CAP_X86_DISABLE_EXITS:
LGTM, will test this and reply on this thread.
On 12 January 2026 04:15:37 GMT, Khushit Shah <khushit.shah@nutanix.com> wrote: > > >> On 2 Jan 2026, at 9:53 PM, David Woodhouse <dwmw2@infradead.org> wrote: >> >> On Mon, 2025-12-29 at 11:17 +0000, Khushit Shah wrote: >>> Extract the suppress EOI broadcast (Directed EOI) logic into helper >>> functions and move the check from kvm_ioapic_update_eoi_one() to >>> kvm_ioapic_update_eoi() (required for a later patch). Prepare >>> kvm_ioapic_send_eoi() to honor Suppress EOI Broadcast in split IRQCHIP >>> mode. >>> >>> Introduce two helper functions: >>> - kvm_lapic_advertise_suppress_eoi_broadcast(): determines whether KVM >>> should advertise Suppress EOI Broadcast support to the guest >>> - kvm_lapic_respect_suppress_eoi_broadcast(): determines whether KVM should >>> honor the guest's request to suppress EOI broadcasts >>> >>> This refactoring prepares for I/O APIC version 0x20 support and userspace >>> control of suppress EOI broadcast behavior. >>> >>> Signed-off-by: Khushit Shah <khushit.shah@nutanix.com> >> >> Looks good to me, thanks for pushing this through to completion! >> >> >> Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> >> >> Nit: Ideally I would would prefer to see an explicit 'no functional >> change intended' and a reference to commit 0bcc3fb95b97a. > > >I took another careful look at the refactor specifically through the >“no functional change” lens. This is, of course, exactly why I make people type those words explicitly :) >The legacy behavior with the in-kernel IRQCHIP can be summarized as: >- Suppress EOI Broadcast (SEOIB) is not advertised to the guest. >- If the guest nevertheless enables SEOIB, it is honored (already in un-s > upported territory). >- Even in that case, the legacy code still ends up calling > kvm_notify_acked_irq() in kvm_ioapic_update_eoi_one(). > >With the refactor, kvm_notify_acked_irq() is no longer reached in this >specific legacy scenario when the guest enables SEOIB despite it not >being advertised. I believe this is acceptable, as the guest is relying >on an unadvertised feature. That sounds sensible as you describe it. Note that we did advertise this in the past and then silently just stop doing so potentially underneath already running guests, but that (commit 0bcc3fb95b97a) was back in 2018 so I guess there won't be many "innocent victim" guests around any more who genuinely did see the feature advertised. >For non-QUIRKED configurations, the behavior is also correct: >- When SEOIB is ENABLED, kvm_notify_acked_irq() is called on EOIR write, > when enabled by guest. >- When SEOIB is DISABLED, kvm_notify_acked_irq() is called on EOI > broadcast. > >I would appreciate others chiming in if they see a reason to preserve >the legacy ack behavior even in the unsupported case. LGTM. Thanks.
© 2016 - 2026 Red Hat, Inc.