Re: [RFC PATCH for-4.22] x86/hvm: Introduce force_x2apic flag

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

Le 30/10/2025 à 08:56, Jan Beulich a écrit :
> On 29.10.2025 19:26, Teddy Astie wrote:
>> --- a/xen/arch/x86/hvm/vlapic.c
>> +++ b/xen/arch/x86/hvm/vlapic.c
>> @@ -1116,6 +1116,20 @@ int guest_wrmsr_apic_base(struct vcpu *v, uint64_t 
>> val)
>>       if ( !has_vlapic(v->domain) )
>>           return X86EMUL_EXCEPTION;
>>
>> +    if ( has_force_x2apic(v->domain) )
>> +    {
>> +        /*
>> +        * We implement the same semantics as MSR_IA32_XAPIC_DISABLE_STATUS:
>> +        * LEGACY_XAPIC_DISABLED which rejects any attempt at clearing
>> +        * IA32_APIC_BASE.EXTD, thus forcing the LAPIC in x2APIC mode.
>> +        */
>
> The MSR aspect should be implemented by using the MSR. Beyond that imo our 
> treatment
> shouldn't be different from that when firmware pre-enables x2APIC: While not
> advisable, aiui OSes could still switch back to xAPIC mode. At which point 
> the guest
> config level control may also want calling "pre-enable", not "force".
>

One advantage of forcing x2APIC enabled is that it simplifies the
support for LAPIC IDs over 255.

While that could be a alternative to just pre-enable x2apic (in cases we
don't want the OS to use xAPIC because it is there), things still gets
tricky for supporting more vCPUs. We would need to clarify the behavior
of enabling xAPIC on a vCPU that has LAPIC_ID > 254, Intel and AMD
specification don't define anything aside for Intel :
> If a BIOS transfers control to OS in xAPIC mode, then the BIOS must ensure 
> that only logical processors with
> CPUID.0BH.EDX value less than 255 are enabled.

And I guess the Intel's MSR_IA32_XAPIC_DISABLE_STATUS exists to prevent
such specific case to occur once the OS booted.

> Jan
>
Teddy


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech