Re: [PATCH 1/2] KVM: x86: Select lowest vCPU ID for aliased xAPIC IDs

[Alejandro Jimenez <alejandro.j.jimenez@oracle.com>]

On 10/30/26 4:12 PM, Sean Christopherson wrote:
> On Wed, Oct 28, 2026, Alejandro Jimenez wrote: > On 10/27/26 4: 25 PM, Sean
> Christopherson wrote: > > On Tue, Oct 27, 2026, Alejandro Jimenez wrote: >
> On 10/27/26 11: 40 AM, > >> The issue was triggered with QEMU and a tool
> 
> On Wed, Oct 28, 2026, Alejandro Jimenez wrote:
>> On 10/27/26 4:25 PM, Sean Christopherson wrote:
>> > On Tue, Oct 27, 2026, Alejandro Jimenez wrote: > On 10/27/26 11: 40 AM,

[...]

> 
>> In short, I think the original proposal of allowing a replacement of a
>> phys_map[xapic_id] entry only with a new "low" entry (i.e. one with vcpu_id
>> == x2apic_id == xapic_id) fixes the creation order issue while preserving
>> the existing behavior for the typical cases.
> 
> Agreed, though I think we tie the overide to "xapic_id <= 0xff" instead of letting
> the "lower" vCPU win.  I.e. to make it a bit more obvious that the goal is to keep
> the non-truncated xAPIC ID reachable.
> 
> Ha!  Yeah, looking at 5bd5db385b3e ("KVM: x86: allow hotplug of VCPU with APIC ID
> over 0xff"), it had:
> 
>                 /*
>                  * ... xAPIC ID of VCPUs with APIC ID > 0xff will wrap-around,
>                  * prevent them from masking VCPUs with APIC ID <= 0xff.
>                  */
>                 if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id])
>                         new->phys_map[xapic_id] = apic;
> 
> so the goal really was to prevent an truncated x2APIC ID from clobbering a "pure"
> xAPIC ID.
> 
> Actually, even better: what if we only let the vCPU whose ID exactly matches the
> aliased xAPIC ID win?  Unless I've gone into the weeds yet again, that's what we
> (and more importantly, userspace and guest firmware) really want.  It shouldn't
> matter in practice, but it lets KVM provide a stronger, and hopefully easier to
> understand, guarantee in the errata.
> 

Sounds good to me.
To confirm: we don't have to worry about resolving aliasing conflicts
between high ID (i.e. >0xff) vCPUs, since they can be addressed by their
full x2APIC IDs even in xapic mode (all hail KVM hotplug hack!), and the
map entry for their aliased xAPIC ID is not required to be updated to
always select the lowest vCPU ID.

But a vCPU with an ID that matches its xAPIC ID will always be allowed to
update its entry on the map, and the proposed code self-documents that.

Let me adjust the selftest, and I'll send v2 with the updates below.

Thank you,
Alejandro

> E.g.
> 
> diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm/x86/errata.rst
> index a9cf0e004651..09c6e6a29ae2 100644
> --- a/Documentation/virt/kvm/x86/errata.rst
> +++ b/Documentation/virt/kvm/x86/errata.rst
> @@ -63,10 +63,11 @@ When KVM_X2APIC_API_USE_32BIT_IDS is enabled, KVM activates a hack/quirk that
>  allows sending events to a single vCPU using its x2APIC ID even if the target
>  vCPU has legacy xAPIC enabled, e.g. to bring up hotplugged vCPUs via INIT-SIPI
>  on VMs with > 255 vCPUs.  A side effect of the quirk is that, if multiple vCPUs
> -have the same physical APIC ID, KVM will deliver events targeting that APIC ID
> -only to the vCPU with the lowest vCPU ID.  If KVM_X2APIC_API_USE_32BIT_IDS is
> -not enabled, KVM follows x86 architecture when processing interrupts (all vCPUs
> -matching the target APIC ID receive the interrupt).
> +have the same physical legacy xAPIC ID, KVM may deliver events targeting that
> +xAPIC ID only to the vCPU whose vCPU ID matches the aliased x2APIC ID.  If
> +KVM_X2APIC_API_USE_32BIT_IDS is not enabled, KVM follows x86 architecture when
> +processing interrupts (all vCPUs matching the target APIC ID receive the
> +interrupt).
>  
>  MTRRs
>  -----
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index d6e5fbc3c58c..e89c4fef1832 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -297,8 +297,8 @@ static int kvm_recalculate_phys_map(struct kvm_apic_map *new,
>  	 * Apply KVM's hotplug hack if userspace has enable 32-bit APIC IDs.
>  	 * Allow sending events to vCPUs by their x2APIC ID even if the target
>  	 * vCPU is in legacy xAPIC mode, and silently ignore aliased xAPIC IDs
> -	 * (the x2APIC ID is truncated to 8 bits, causing IDs > 0xff to wrap
> -	 * and collide).
> +	 * but make sure the non-truncated xAPIC ID always "wins" (the x2APIC
> +	 * ID is truncated to 8 bits, causing IDs > 0xff to wrap and collide).
>  	 *
>  	 * Honor the architectural (and KVM's non-optimized) behavior if
>  	 * userspace has not enabled 32-bit x2APIC IDs.  Each APIC is supposed
> @@ -312,7 +312,8 @@ static int kvm_recalculate_phys_map(struct kvm_apic_map *new,
>  		if (apic_x2apic_mode(apic) || x2apic_id > 0xff)
>  			new->phys_map[x2apic_id] = apic;
>  
> -		if (!apic_x2apic_mode(apic) && !new->phys_map[xapic_id])
> +		if (!apic_x2apic_mode(apic) &&
> +		    (!new->phys_map[xapic_id] || vcpu->vcpu_id == xapic_id))
>  			new->phys_map[xapic_id] = apic;
>  	} else {
>  		/*
>