linux-kernel - Re: [PATCH] KVM: x86: skip userspace IOAPIC EOI exit when Directed EOI is enabled

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <EFA9296F-14F7-4D78-9B7C-1D258FF0A97A@nutanix.com>
Date: Fri, 31 Oct 2025 12:46:58 +0000
From: Khushit Shah <khushit.shah@...anix.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Jon Kohler <jon@...anix.com>, Paolo Bonzini <pbonzini@...hat.com>,
        Thomas
 Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav
 Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KVM: x86: skip userspace IOAPIC EOI exit when Directed
 EOI is enabled

Hi Sean,

Thanks for the reply.

> On 25 Oct 2025, at 1:51 AM, Sean Christopherson <seanjc@...gle.com> wrote:
> 
> Make it a quirk instead of a capability.  This is definitely a KVM bug, it's just
> unfortunately one that we can't fix without breaking userspace :-/

I don’t think this approach fully addresses the issue.

For example, consider the same Windows guest running with a userspace
I/O APIC that has no EOI registers. The guest will set the Suppress EOI
Broadcast bit because KVM advertises support for it (see 
kvm_apic_set_version).

If the quirk is enabled, an interrupt storm will occur.
If the quirk is disabled, userspace will never receive the EOI
notification.

For context, Windows with CG the interrupt in the following order:
  1. Interrupt for L2 arrives.
  2. L1 APIC EOIs the interrupt.
  3. L1 resumes L2 and injects the interrupt.
  4. L2 EOIs after servicing.
  5. L1 performs the I/O APIC EOI.

Guest is not doing anything theoretically wrong here. 

The root issue is that KVM advertises support for EOI broadcast
suppression without knowing whether userspace supports it.

Even my previous proposal doesn’t completely solve this. A potential
way to fix it without breaking userspace would be to let userspace
explicitly indicate whether it supports EOI broadcast suppression
(i.e. whether it implements EOI registers). By default, KVM should
assume userspace does *not* support EOI broadcast suppression,
contrary to the current behavior.

This way, unmodified userspace remains unaffected, and updated
userspace can opt in when it truly supports EOI broadcast suppression.

Am I missing something?

Regards,
Khushit