mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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().




  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®