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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.10.2025 15:33, Teddy Astie wrote:
> 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.

Well, this falls into the much wider topic of making more than 128 vCPU-s
available for HVM / PVH, doesn't it?

Jan