Re: [PATCH v2 2/2] x86/fpu: Split fpu_setup_fpu() in two

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.08.2024 15:41, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1164,10 +1164,25 @@ static int cf_check hvm_load_cpu_ctxt(struct domain 
> *d, hvm_domain_context_t *h)
>      seg.attr = ctxt.ldtr_arbytes;
>      hvm_set_segment_register(v, x86_seg_ldtr, &seg);
>  
> -    /* Cover xsave-absent save file restoration on xsave-capable host. */
> -    vcpu_setup_fpu(v, xsave_enabled(v) ? NULL : v->arch.xsave_area,
> -                   ctxt.flags & XEN_X86_FPU_INITIALISED ? ctxt.fpu_regs : 
> NULL,
> -                   FCW_RESET);
> +    /*
> +     * On Xen 4.1 and later the FPU state is restored on later HVM context in
> +     * the migrate stream, so what we're doing here is initialising the FPU
> +     * state for guests from even older versions of Xen.
> +     *
> +     * In particular:
> +     *   1. If there's an XSAVE context later in the stream what we do here 
> for
> +     *      the FPU doesn't matter because it'll be overriden later.
> +     *   2. If there isn't and the guest didn't use extended states it's 
> still
> +     *      fine because we have all the information we need here.
> +     *   3. If there isn't and the guest DID use extended states (could've
> +     *      happened prior to Xen 4.1) then we're in a pickle because we have
> +     *      to make up non-existing state. For this case we initialise the 
> FPU
> +     *      as using x87/SSE only because the rest of the state is gone.

Was this really possible to happen? Guests wouldn't have been able to
turn on CR4.OSXSAVE, would they?

Jan