On Thu, 2025-12-11 at 10:59 +0000, Khushit Shah wrote:
+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, which is to advertise support for Suppress EOI Broadcasts but +not actually suppressing EOI broadcasts.
"which is to... not actually suppressing EOI broadcasts."
I think you want s/suppressing/suppress/ there.
+Currently, both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and
I don't much like the word 'both' at the start of the sentence. It sent my brain down a language-recognition path which thought it was about setting both bits at the same time, and may lead to misunderstandings or just slower parsing of the sentence.
+KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST must only be set when in split IRQCHIP +mode. Otherwise, the ioctl will fail with an EINVAL error.
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.)