Re: [PATCH v1 2/8] x86/vmx: Remove lazy FPU support

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/03/2026 4:43 pm, Jan Beulich wrote:
> On 19.03.2026 17:38, Andrew Cooper wrote:
>> On 19/03/2026 1:29 pm, Ross Lagerwall wrote:
>>> Remove lazy FPU support from the VMX code since fully_eager_fpu is now
>>> always true.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>
>>> ---
>>>  xen/arch/x86/hvm/vmx/vmcs.c             |  8 +--
>>>  xen/arch/x86/hvm/vmx/vmx.c              | 70 +------------------------
>>>  xen/arch/x86/hvm/vmx/vvmx.c             | 15 +-----
>>>  xen/arch/x86/include/asm/hvm/vmx/vmcs.h |  2 -
>>>  4 files changed, 5 insertions(+), 90 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
>>> index c2e7f9aed39f..8e52ef4d497a 100644
>>> --- a/xen/arch/x86/hvm/vmx/vmcs.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
>>> @@ -1247,10 +1247,7 @@ static int construct_vmcs(struct vcpu *v)
>>>      __vmwrite(HOST_TR_SELECTOR, TSS_SELECTOR);
>>>  
>>>      /* Host control registers. */
>>> -    v->arch.hvm.vmx.host_cr0 = read_cr0() & ~X86_CR0_TS;
>>> -    if ( !v->arch.fully_eager_fpu )
>>> -        v->arch.hvm.vmx.host_cr0 |= X86_CR0_TS;
>>> -    __vmwrite(HOST_CR0, v->arch.hvm.vmx.host_cr0);
>>> +    __vmwrite(HOST_CR0, read_cr0());
>> (Not for this patch) but I'm pretty sure there's room to optimise this
>> further.
>>
>> CR0 should be constant, both here and in SVM.  Reading the active cr0 is
>> an example of the anti-pattern we need to purge to make nested-virt work
>> better.
> In which case, is it a good idea to purge the host_cr0 field?

Oh hmm, I take back my R-by slightly.  We still need to initialise
v->arch.hvm.vmx.host_cr0 for this patch to be no functional change. 
Easy enough to fix, or fix on commit.

That said, I think we probably do want to purge host_cr0 eventually.

There are a few cases where host_cr0 != guest_cr0.  CPUs prior to
unrestricted_guest are the obvious case, where we can't run with CR0.PE
!= 1, but this should always be derivable from guest_cr0 and the
hardware capabilities.

~Andrew