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


Re: [Xen-devel] RFC: 32 bits as smallest atomic size.

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: 32 bits as smallest atomic size.
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 29 Mar 2005 15:39:17 -0600
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 29 Mar 2005 21:41:41 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <74f362598b4e1a0d46aacb1a514706ac@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: <16964.33214.921809.324278@xxxxxxxxxxxxxxxxxxxxx> <74f362598b4e1a0d46aacb1a514706ac@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[Resending to really correct list this time.]

On Fri, 2005-03-25 at 21:43 +0000, Keir Fraser wrote:
> I expect we can fix that up in the ppc macros: if the atomic access is 
> sub-32-bit aligned then round the address down to 32-bit boundary and 
> do a 32-bit cmpxchg.

>From a quick survey of Linux headers, it seems at least the following
architectures only support 4/8-byte atomic instructions: ppc(64),
sparc(64), parisc, mips, alpha.

The following architectures support 1/2-byte atomic instructions:
x86(64), ia64.

Since so many architectures don't allow non-word-sized accesses (a link
error is triggered), common Linux code does not make such calls. Could
we please have the same policy?

Right now there is a single problematic cmpxchg user, grant_entry_t, and
the impact of the fix is tiny (make the 'flags' member 4 bytes). Is that
too large an inconvenience?

Hollis Blanchard
IBM Linux Technology Center

Xen-devel mailing list