WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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