|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 3/4] xen/hvm: introduce a fpu_uninitialised field to the CPU save record
>>> On 18.11.15 at 17:37, <roger.pau@xxxxxxxxxx> wrote:
> @@ -2091,7 +2092,8 @@ static int hvm_load_cpu_ctxt(struct domain *d,
> hvm_domain_context_t *h)
> struct xsave_struct *xsave_area = v->arch.xsave_area;
>
> memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
> - xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE;
> + xsave_area->xsave_hdr.xstate_bv = ctxt.fpu_initialised ?
> + XSTATE_FP_SSE : 0;
> }
> else
> memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs));
Question is - are the memcpy()s here really meaningful/valid
when !ctxt.fpu_initialized? I.e. shouldn't this code rather be
skipped instead of getting modified?
> @@ -157,6 +159,8 @@ struct hvm_hw_cpu {
> };
> /* error code for pending event */
> uint32_t error_code;
> + /* is fpu initialised? */
> + uint32_t fpu_initialised;
A whole uint32_t for just one bit? Didn't we talk about making this
new field a flags one, consuming just one bit from it?
> @@ -266,6 +270,7 @@ struct hvm_hw_cpu_compat {
> };
> /* error code for pending event */
> uint32_t error_code;
> + /*uint32_t fpu_initialised; COMPAT */
> };
I think this is misleading - the compat structure never has this field.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |