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
