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

[Alexandru Stefan ISAILA <aisaila@bitdefender.com>]

On Vi, 2018-07-13 at 04:29 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 13.07.18 at 11:04, <aisaila@bitdefender.com> 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 ={}?

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