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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: zero and check vcpu context __pad field



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 30 March 2016 14:17
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
> Subject: RE: [PATCH] x86/hvm/viridian: zero and check vcpu context __pad
> field
> 
> >>> On 30.03.16 at 13:26, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 30 March 2016 12:23
> >> >>> On 30.03.16 at 12:32, <paul.durrant@xxxxxxxxxx> wrote:
> >> > --- a/xen/arch/x86/hvm/viridian.c
> >> > +++ b/xen/arch/x86/hvm/viridian.c
> >> > @@ -824,6 +824,8 @@ static int viridian_save_vcpu_ctxt(struct domain
> *d,
> >> hvm_domain_context_t *h)
> >> >      for_each_vcpu( d, v ) {
> >> >          struct hvm_viridian_vcpu_context ctxt;
> >> >
> >> > +        memset(&ctxt, 0, sizeof(ctxt));
> >>
> >> How about just adding an empty initializer to the declaration?
> >>
> >
> > I think having a 'zero the entire struct' call at the start is better as it
> > will cover any additions made to the struct in future. It's what I had
> > mistakenly assumed was already there. In fact I think adding a similar call
> > into the domain context save function would probably be worthwhile.
> 
> And how does the initializer approach not fulfill that intention?
> 

Because any time anyone adds another field they have to remember to add another 
initializer, which is what I forgot to do. This approach OTOH is failsafe.

  Paul

> 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®.