[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |