From: Khushit Shah <khushit.shah@nutanix.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "seanjc@google.com" <seanjc@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"kai.huang@intel.com" <kai.huang@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"x86@kernel.org" <x86@kernel.org>, "bp@alien8.de" <bp@alien8.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Jon Kohler <jon@nutanix.com>,
Shaju Abraham <shaju.abraham@nutanix.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v4] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression
Date: Fri, 12 Dec 2025 07:08:23 +0000 [thread overview]
Message-ID: <B45DB519-3B04-46F7-894E-42A44DF2FC8E@nutanix.com> (raw)
In-Reply-To: <83cf40c6168c97670193340b00d0fe71a35a6c1b.camel@infradead.org>
> 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().
next prev parent reply other threads:[~2025-12-12 7:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 10:59 Khushit Shah
2025-12-11 18:59 ` Sean Christopherson
2025-12-12 5:44 ` Khushit Shah
2025-12-11 21:05 ` Huang, Kai
2025-12-12 0:01 ` David Woodhouse
2025-12-12 0:10 ` Sean Christopherson
2025-12-12 1:11 ` David Woodhouse
2025-12-12 7:08 ` Khushit Shah [this message]
2025-12-12 7:31 ` David Woodhouse
2025-12-12 8:16 ` Khushit Shah
2025-12-12 8:19 ` David Woodhouse
2025-12-12 8:27 ` Khushit Shah
2025-12-12 8:30 ` David Woodhouse
2025-12-17 12:06 ` Khushit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B45DB519-3B04-46F7-894E-42A44DF2FC8E@nutanix.com \
--to=khushit.shah@nutanix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=hpa@zytor.com \
--cc=jon@nutanix.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shaju.abraham@nutanix.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®