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/
Home Products Support Community News


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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 27 Jun 2006 10:06:54 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Jun 2006 08:06:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46ab924009436680faa7cc0cb807c411@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <1151097564.14454.44.camel@xxxxxxxxxxxxxxxxxxxxx> <46ab924009436680faa7cc0cb807c411@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-06-27 at 11:39 +0100, Keir Fraser wrote:
> On 23 Jun 2006, at 22:19, Hollis Blanchard wrote:
> > These patches are similar to changeset 10747 (which added
> > vcpu_mark_events_pending), in that they allow PPC to work around some
> > unusually-sized atomic operations, this time in the grant table driver.
> >
> > Keir, do you think it's a good idea to make a wiki page to list where
> > the current ABI is causing problems? That way, when the ABI opens up
> > again (Xen 4?), we'll have a list of places to fix?
> >
> > Anyways, I expect you'll have alternate name/interface suggestions in
> > the patches, so they're just RFC for now.
> You should be able to hide all this behind the generic atomic 
> operations without slowing down sufficiently aligned operations at all.
> e.g. something like:
> define clear_bit(p,i) ((alignof(p)>=alignof(long)) ? clear_bit(p,i) : 
> clear_bit_unaligned(p,i))

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

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list