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".
Jan
