[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea294969d05fc9c37e72053d7343e11fa9ffdded.camel@infradead.org>
Date: Tue, 27 Jan 2026 14:36:57 -0800
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Khushit Shah <khushit.shah@...anix.com>, pbonzini@...hat.com,
kai.huang@...el.com, mingo@...hat.com, x86@...nel.org, bp@...en8.de,
hpa@...or.com, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
dave.hansen@...ux.intel.com, tglx@...utronix.de, jon@...anix.com,
shaju.abraham@...anix.com, stable@...r.kernel.org
Subject: Re: [PATCH v6] KVM: x86: Add x2APIC "features" to control EOI
broadcast suppression
On Tue, 2026-01-27 at 13:49 -0800, Sean Christopherson wrote:
>
> Nope, we should be good on that front, kvm->arch.irqchip_mode can't be changed
> once its set. I.e. the irqchip_split() check could get a false negative if it's
> racing with KVM_CREATE_IRQCHIP, but it can't get a false positive and thus
> incorrectly allow KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST.
Ah, so userspace which checks all the kernel's capabilities *first*
will not see KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST advertised,
because it needs to enable KVM_CAP_SPLIT_IRQCHIP first?
I guess that's tolerable¹ but the documentation could make it clearer,
perhaps? I can see VMMs silently failing to detect the feature because
they just don't set split-irqchip before checking for it?
¹ although I still kind of hate it and would have preferred to have the
I/O APIC patch; userspace still has to intentionally *enable* that
combination. But OK, I've reluctantly conceded that.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists