[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [V6 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen



>>> On 15.10.15 at 03:58, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 13, 2015 at 07:49:12AM -0600, Jan Beulich wrote:
>> >>> On 12.10.15 at 08:07, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
>> 
>> > @@ -2257,9 +2261,14 @@ static int hvm_load_cpu_xsave_states(struct domain 
> *d, hvm_domain_context_t *h)
>> >      v->arch.xcr0_accum = ctxt->xcr0_accum;
>> >      if ( ctxt->xcr0_accum & XSTATE_NONLAZY )
>> >          v->arch.nonlazy_xstate_used = 1;
>> > -    memcpy(v->arch.xsave_area, &ctxt->save_area,
>> > -           min(desc->length, size) - offsetof(struct hvm_hw_cpu_xsave,
>> > -           save_area));
>> > +    if ( (cpu_has_xsaves || cpu_has_xsavec) )
>> > +        compress_xsave_states(v, &ctxt->save_area,
>> > +                              min(desc->length, size) -
>> > +                              offsetof(struct 
> hvm_hw_cpu_xsave,save_area));
>> > +    else
>> > +        memcpy(v->arch.xsave_area, &ctxt->save_area,
>> > +               min(desc->length, size) - offsetof(struct hvm_hw_cpu_xsave,
>> > +               save_area));
>> 
>> Each time I look at these two hunks I wonder whether the condition
>> and memcpy() wouldn't better move into the new called functions.
>> 
> Will func name 
> void load_xsave_area(struct vcpu *v, struct hvm_hw_cpu_xsave *ctxt)
> void save_xsave_area(struct vcpu *v, struct hvm_hw_cpu_xsave *ctxt)
> Ok ?

Yes, or just keep the current names. (As a side note - one of the
two clearly wants its second argument constified.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.