Re: [Xen-devel] [PATCH v11 01/11] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.07.18 at 13:19, <aisaila@xxxxxxxxxxxxxxx> wrote:
> On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
>> > 
>> > > 
>> > > > 
>> > > > On 13.07.18 at 11:04, <aisaila@xxxxxxxxxxxxxxx> wrote:
>> > Changes since V10:
>> >    - Add memset to 0 for ctxt.
>> Why? What's wrong with ...
>> 
>> > 
>> > --- a/xen/arch/x86/cpu/mcheck/vmce.c
>> > +++ b/xen/arch/x86/cpu/mcheck/vmce.c
>> > @@ -349,6 +349,20 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
>> >      return ret;
>> >  }
>> >  
>> > +static int vmce_save_vcpu_ctxt_one(struct vcpu *v,
>> > hvm_domain_context_t *h)
>> > + {
>> > +    struct hvm_vmce_vcpu ctxt;
>> > +
>> > +    memset(&ctxt, 0, sizeof(ctxt));
>>     struct hvm_vmce_vcpu ctxt = {};
>> 
>> instead? Or even pulling all of this ...
>> 
>> > 
>> > +    ctxt.caps = v->arch.vmce.mcg_cap;
>> > +    ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
>> > +    ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
>> > +    ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
>> ... into the initializer, which will make sure padding fields are
>> zero.
>> I can see that a memset() is warranted in _some_ cases, but not
>> uniformly.
> 
> The memset solution was introduced to have consistency with other
> save_one funcs like hvm_save_cpu_ctxt_one(), hvm_save_mtrr_msr_one(),
> and viridian_save_vcpu_ctxt_one(). They all have memset to 0 fot the
> ctxt variables. Should I keep it with memset or change them all to ={}?

This depends on context.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel