[Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Tue, 2006-06-27 at 16:24 +0100, Keir Fraser wrote:
> On 27 Jun 2006, at 16:06, Hollis Blanchard wrote:
> 
> > In the couple cases so far, we know that even though the field is only
> > one or two bytes, it's actually safe to do a four-byte load/store to it
> > because the containing structure is large enough.
> >
> > I'm not really comfortable with making that a blanket assumption. I'd
> > really like to know exactly what we're overwriting when performing 
> > these
> > hacks^Woperations.
> 
> You won't be overwriting anything else since you'll be performing an 
> atomic read-modify-write that does not change any of the bits outside 
> the subword of interest. More precisely, you may overwrite those bits 
> outside the subword, but it's guaranteed to be with the current 
> contents so there'll be no externally visible change and you won't 
> clobber anything.

Right, I'm not worried about clobbering data. I am a little worried
about false conflicts in the reservations. Atomics on PPC, and many
other processors, are implemented as "load with reservation; conditional
store", where conditional store fails if another processor conflicted
with the reservation. I think typically a processor only has a single
reservation. Practically speaking this probably isn't likely to hit us,
but the whole thing is really making me uncomfortable.

> Since you'll do an aligned longword operation you 
> can't end up straddling a page boundary or anything nasty like that.

OK, that's a good point.

In general I'm skeptical of blindly performing these operations on
unknown data. I think it's pretty clear that is not a good interface,
and what you're suggesting is codifying this behavior in the interface.

More practically speaking, I would be shocked if the Linux maintainers
would accept that sort of change to their atomic interfaces.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel