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

> > 
> > > @@ -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'.
> 
> I hear you, but all of KVM's quirks are phrased exactly like this:
> 
>   KVM_CAP_DISABLE_QUIRKS
>   KVM_CAP_DISABLE_QUIRKS2
>   KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK
>   disable_slot_zap_quirk

Fair enough.  It follows KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK which
disables a quirk named "broadcast".

I was looking at below though:

#define KVM_X86_QUIRK_LINT0_REENABLED           (1 << 0)                   
#define KVM_X86_QUIRK_CD_NW_CLEARED             (1 << 1)                   
#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE           (1 << 2)                   
#define KVM_X86_QUIRK_OUT_7E_INC_RIP            (1 << 3)                   
#define KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT      (1 << 4)                   
#define KVM_X86_QUIRK_FIX_HYPERCALL_INSN        (1 << 5)                   
#define KVM_X86_QUIRK_MWAIT_NEVER_UD_FAULTS     (1 << 6)                   
#define KVM_X86_QUIRK_SLOT_ZAP_ALL              (1 << 7)                   
#define KVM_X86_QUIRK_STUFF_FEATURE_MSRS        (1 << 8)                   
#define KVM_X86_QUIRK_IGNORE_GUEST_PAT          (1 << 9)            

Where we can tell very clearly about the name of the quirk.

And AFAICT the name tells what KVM actually does (I didn't check them all
though) -- e.g., for the SLOT_ZAP_ALL quirk, when a VM has this quirk, KVM
zaps all rather than only one slot.

I guess this was how I got confused about "SUPPRESS_EOI_BROADCAST" quirk --
I thought it was "KVM suppresses EOI broadcast while it should not", but it
actually means opposite ...

> 
> > And in either case, the final meaning is KVM needs to "disable suppress EOI
> > broadcast" when that boolean is true, 
> 
> No.  The flag says "Disable KVM's 'Suppress EOI-broadcast' Quirk", where the
> quirk is that KVM always broadcasts even when broadcasts are supposed to be
> suppressed.

... as you said here. :-)

> 
> > 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?
> 
> Hmm, I wanted to specifically call out that the behavior is a quirk.  At the
> risk of being too verbose, maybe DISABLE_IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK?

I think it reflects the behaviour of the quirk more, thus I kinda prefer
this.

> 
> And then to keep line lengths sane, grab "kvm" locally so that we can end up with:
> 
> 	/* Request a KVM exit to inform the userspace IOAPIC. */
> 	if (irqchip_split(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) &&
> 		    kvm->arch.disable_ignore_suppress_eoi_broadcast_quirk)
> 			return;
> 
> > 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.
> 
> Eh, I'd prefer to solve that through documentation and comments.  The name is
> already brutally long.

I still kinda prefer the explicitness but no problem of skipping this part.

Btw, hate to say, but the existing x2 apic macros have an "_API" postfix
after "KVM_X2APIC":

#define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)

>  
> > 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.
> 
> It's also wrong.  Directed EOI is the I/O APIC feature, the local APIC (CPU)
> feature is "Suppress EOI-broadcasts" or "EOI-broadcast suppression".  Conflating
> those two features is largely what led to this mess in the first place, so I'd
> strongly prefer not to bleed that confusion into KVM's uAPI.

OK fair enough.

  reply	other threads:[~2025-11-05 21:33 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
2025-11-05 16:33               ` Sean Christopherson
2025-11-05 21:33                 ` Huang, Kai [this message]
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=d78f865ccb5acbf4363d02592762c8830c707298.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®