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
