From: David Woodhouse <dwmw2@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Khushit Shah <khushit.shah@nutanix.com>,
pbonzini@redhat.com, kai.huang@intel.com, mingo@redhat.com,
x86@kernel.org, bp@alien8.de, hpa@zytor.com,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
dave.hansen@linux.intel.com, tglx@linutronix.de,
jon@nutanix.com, shaju.abraham@nutanix.com
Subject: Re: [PATCH v5 4/3] KVM: selftests: Add test cases for EOI suppression modes
Date: Thu, 29 Jan 2026 07:58:41 -0800 [thread overview]
Message-ID: <da810fb5204a88c352ca3983e0b2e27b485b33e7.camel@infradead.org> (raw)
In-Reply-To: <aXt6ZEgZRGPPPtTB@google.com>
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
On Thu, 2026-01-29 at 07:19 -0800, Sean Christopherson wrote:
> On Wed, Jan 28, 2026, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> >
> > Rather than being frightened of doing the right thing for the in-kernel
> > I/O APIC because "there might be bugs",
>
> I'm not worried about bugs per se, I'm worried about breaking existing guests.
> Even if KVM is 100% perfect, changes in behavior can still break guests,
> especially for a feature like this where it seems like everyone got it wrong.
There's the potential for guest bugs when the local APIC actually
starts honouring the DIRECTED_EOI bit in the SPIV register, sure. At
that point, the guest *has* to do the direct EOI (and it has to work).
But that's why we kept the 'quirk' mode as the default unless userspace
explicitly opts in. And it's true for the split-irqchip too; fixing the
behaviour is the whole point of this exercise.
I don't see why supporting precisely the same behaviour in the kernel
irqchip is any different in that respect.
> And as I said before, I'm not opposed to supporting directed EOI in the in-kernel
> I/O APIC, but (a) I don't want to do it in conjunction with the fixes for stable@,
> and (b) I'd prefer to not bother unless there's an actual use case for doing so.
> The in-kernel I/O APIC isn't being deprecated, but AFAIK it's being de-prioritized
> by pretty much every VMM. I.e. the risk vs. reward isn't there for me.
I tend to favour the simplicity, with _ENABLE and _DISABLE just quietly
doing what their name implies without any of that nonsense about
"except if you have a kernel irqchip".
But as you wish. Most of this test case should be fine on v6 of the
patch which dropped in-kernel I/O APIC support. All the tests are
conditional on the corresponding support being advertised, so it just
needs updating to correctly detect the in-kernel _ENABLE support in
case that does get added. How did we say we would advertise that?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
next prev parent reply other threads:[~2026-01-29 15:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 11:17 [PATCH v5 0/3] KVM: x86: Add userspace control for Suppress EOI Broadcast Khushit Shah
2025-12-29 11:17 ` [PATCH v5 1/3] KVM: x86: Refactor suppress EOI broadcast logic Khushit Shah
2026-01-02 16:23 ` David Woodhouse
2026-01-12 4:15 ` Khushit Shah
2026-01-13 23:40 ` David Woodhouse
2026-01-14 0:10 ` Sean Christopherson
2026-01-16 4:41 ` Khushit Shah
2026-01-16 9:01 ` David Woodhouse
2026-01-16 10:02 ` Khushit Shah
2026-01-16 17:34 ` Sean Christopherson
2026-01-23 13:04 ` Khushit Shah
2026-01-13 23:11 ` Sean Christopherson
2025-12-29 11:17 ` [PATCH v5 2/3] KVM: x86/ioapic: Implement support for I/O APIC version 0x20 with EOIR Khushit Shah
2025-12-29 11:39 ` David Woodhouse
2025-12-29 12:21 ` Khushit Shah
2025-12-29 13:01 ` David Woodhouse
2025-12-29 15:16 ` Khushit Shah
2025-12-29 15:36 ` David Woodhouse
2025-12-29 15:57 ` Khushit Shah
2026-01-02 16:17 ` David Woodhouse
2026-01-12 3:22 ` Khushit Shah
2025-12-29 11:17 ` [PATCH v5 3/3] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression Khushit Shah
2026-01-02 16:41 ` David Woodhouse
2026-01-12 3:27 ` Khushit Shah
2026-01-29 4:49 ` [PATCH v5 4/3] KVM: selftests: Add test cases for EOI suppression modes David Woodhouse
2026-01-29 15:19 ` Sean Christopherson
2026-01-29 15:58 ` David Woodhouse [this message]
2026-02-04 0:00 ` Sean Christopherson
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=da810fb5204a88c352ca3983e0b2e27b485b33e7.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jon@nutanix.com \
--cc=kai.huang@intel.com \
--cc=khushit.shah@nutanix.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=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®