Re: [PATCH v5 4/3] KVM: selftests: Add test cases for EOI suppression modes

[David Woodhouse]

On Thu, 2026-01-29 at 07:19 -0800, Sean Christopherson wrote:
> On Wed, Jan 28, 2026, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > 
> > 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: smime.p7s
Description: S/MIME cryptographic signature