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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <da810fb5204a88c352ca3983e0b2e27b485b33e7.camel@infradead.org>
Date: Thu, 29 Jan 2026 07:58:41 -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
Subject: Re: [PATCH v5 4/3] KVM: selftests: Add test cases for EOI
 suppression modes

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.

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

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)