[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V6 1/2] x86/xsaves: calculate the comp_offsets base on xcomp_bv
On Tue, Mar 29, 2016 at 08:35:34AM -0600, Jan Beulich wrote: > >>> On 24.03.16 at 09:29, <shuai.ruan@xxxxxxxxxxxxxxx> wrote: > > static void *get_xsave_addr(struct xsave_struct *xsave, > > - unsigned int xfeature_idx) > > + const uint16_t *comp_offsets, > > + unsigned int xfeature_idx) > > { > > if ( !((1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv) ) > > return NULL; > > While not a problem in this patch, I think this being at least > questionable now becomes more obvious: With XSAVEC and > XSAVES this field may have clear bits just because the > component was in init state. Yet I don't think this should be > fixed here - instead the consumer(s) should better deal with > NULL coming back here (i.e. expand_xsave_states() should > probably memset() the area in an "else" to the if() leading to > memcpy(), whereas compress_xsave_states() is fine as is). > > That's a 3rd patch, though. > I will add code only in expand_xsave_states() to deal with NULL returned by get_xsave_addr(). > > + return (void *)xsave + (xsave_area_compressed(xsave) ? > > + comp_offsets[xfeature_idx] : > > + xstate_offsets[xfeature_idx]); > > This function doesn't ever get called when > !xsave_area_compressed(xsave), so I don't really see why this > conditional expression ever got added. Yet another follow-up > patch I would say. I will drop this. > > The patch here looks okay to me now. > Thanks > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |