mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "khushit.shah@nutanix.com" <khushit.shah@nutanix.com>,
	"seanjc@google.com" <seanjc@google.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>, "bp@alien8.de" <bp@alien8.de>,
	"Kohler, Jon" <jon@nutanix.com>, "hpa@zytor.com" <hpa@zytor.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>
Subject: Re: [PATCH] KVM: x86: skip userspace IOAPIC EOI exit when Directed EOI is enabled
Date: Tue, 4 Nov 2025 09:55:36 +0000	[thread overview]
Message-ID: <cc6de4bfd9fbe0c7ac48b138681670d113d2475e.camel@intel.com> (raw)
In-Reply-To: <aQTxoX4lB_XtZM-w@google.com>


[...]


> KVM's bogus handling of Supress EOI Broad is problematic when the guest
> relies on interrupts being masked in the I/O APIC until well after the
> initial local APIC EOI.  E.g. Windows with Credential Guard enabled
> handles interrupts in the following order:
> 
>  the interrupt in the following order:

This sentence is broken and is not needed.

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

[...]

> @@ -1517,6 +1518,18 @@ static void kvm_ioapic_send_eoi(struct kvm_lapic *apic, int vector)
>  
>  	/* Request a KVM exit to inform the userspace IOAPIC. */
>  	if (irqchip_split(apic->vcpu->kvm)) {
> +		/*
> +		 * Don't exit to userspace if the guest has enabled Directed
> +		 * EOI, a.k.a. Suppress EOI Broadcasts, in which case the local
> +		 * APIC doesn't broadcast EOIs (the guest must EOI the target
> +		 * I/O APIC(s) directly).  Ignore the suppression if userspace
> +		 * has NOT disabled KVM's quirk (KVM advertised support for
> +		 * Suppress EOI Broadcasts without actually suppressing EOIs).
> +		 */
> +		if ((kvm_lapic_get_reg(apic, APIC_SPIV) & APIC_SPIV_DIRECTED_EOI) &&
> +		    apic->vcpu->kvm->arch.disable_suppress_eoi_broadcast_quirk)
> +			return;
> +

I found the name 'disable_suppress_eoi_broadcast_quick' is kinda confusing,
since it can be interpreted in two ways:

 - the quirk is 'suppress_eoi_broadcast', and this boolean is to disable
   this quirk.
 - the quirk is 'disable_suppress_eoi_broadcast'.

And in either case, the final meaning is KVM needs to "disable suppress EOI
broadcast" when that boolean is true, which in turn means KVM actually needs
to "broadcast EOI" IIUC.  But the above check seems does the opposite.

Perhaps "ignore suppress EOI broadcast" in your previous version is better?

Also, IIUC the quirk only applies to userspace IOAPIC, so is it better to
include "split IRQCHIP" to the name?  Otherwise people may think it also
applies to in-kernel IOAPIC.

Btw, personally I also found "directed EOI" is more understandable than
"suppress EOI broadcast".  How about using "directed EOI" in the code
instead?  E.g.,

 s/disable_suppress_eoi_broadcast/disable_directed_eoi
 s/KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST/KVM_X2APIC_DISABLE_DIRECTED_EOI
	
It is shorter, and KVM is already using APIC_LVR_DIRECTED_EOI anyway.

  parent reply	other threads:[~2025-11-04  9:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 16:25 Jon Kohler
2025-09-22 21:51 ` Sean Christopherson
2025-09-23  1:26   ` Huang, Kai
2025-09-23  3:32   ` Khushit Shah
2025-10-03 14:24     ` Khushit Shah
2025-10-24 20:21       ` Sean Christopherson
2025-10-31 12:46         ` Khushit Shah
2025-10-31 17:28           ` Sean Christopherson
2025-11-03  4:36             ` Khushit Shah
2025-11-03 16:57               ` Sean Christopherson
2025-11-04  5:08                 ` Khushit Shah
2025-11-04  9:55             ` Huang, Kai [this message]
2025-11-05 16:33               ` Sean Christopherson
2025-11-05 21:33                 ` Huang, Kai
2025-10-24 12:08 ` Khushit Shah

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=cc6de4bfd9fbe0c7ac48b138681670d113d2475e.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jon@nutanix.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=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®