Message-ID: <aYKMGGttusuMI2QU@google.com>
Date: Tue, 3 Feb 2026 16:00:24 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: David Woodhouse <dwmw2@...radead.org>
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
Subject: Re: [PATCH v5 4/3] KVM: selftests: Add test cases for EOI suppression modes

On Thu, Jan 29, 2026, David Woodhouse wrote:
> On Thu, 2026-01-29 at 07:19 -0800, Sean Christopherson wrote:
> > On Wed, Jan 28, 2026, David Woodhouse wrote:
> > > From: David Woodhouse <dwmw@...zon.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.

Conceptually, nothing.  But fixing the in-kernel I/O APIC is more invasive, it's
not currently broken (KVM doesn't advertise DIRECTED_EOI or SUPPRESS_EOI_BROADCAST),
no one is lining up to actually utilizes the functionality, *and* there are some
historical warts in KVM that need to be addressed.

Add it all up, and for me at least, the risk vs. reward is very different for
split vs. fully in-kernel irqchips.

> > 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 they _don't_ do what their name implies if there's no in-kernel local APIC.
I.e. userspace needs to read the docs and do the right thing anyways.

> 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?

A doc update plus this:

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 67e666921a12..d711493f9c69 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4934,7 +4934,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
                break;
        case KVM_CAP_X2APIC_API:
                r = KVM_X2APIC_API_VALID_FLAGS;
-               if (kvm && !irqchip_split(kvm))
+               if (kvm && !irqchip_in_kernel(kvm))
                        r &= ~KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST;
                break;
        case KVM_CAP_NESTED_STATE:

Powered by blists - more mailing lists