From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J12oY-0007vD-Ic for qemu-devel@nongnu.org; Sat, 08 Dec 2007 11:46:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J12oV-0007qI-Ma for qemu-devel@nongnu.org; Sat, 08 Dec 2007 11:46:06 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J12oV-0007qB-JB for qemu-devel@nongnu.org; Sat, 08 Dec 2007 11:46:03 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J12oU-0000cQ-Qd for qemu-devel@nongnu.org; Sat, 08 Dec 2007 11:46:03 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device Date: Sat, 8 Dec 2007 16:45:56 +0000 References: <4755CC8C.6000001@us.ibm.com> <200712081322.39762.paul@codesourcery.com> <20071208140906.GA22712@shareable.org> In-Reply-To: <20071208140906.GA22712@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712081645.57284.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Anthony Liguori , Rusty Russell On Saturday 08 December 2007, Jamie Lokier wrote: > Paul Brook wrote: > > > virtio makes things a bit trickier though. There's a shared ring queue > > > between the host and guest. The ring queue is lock-less and depends on > > > the ability to atomically increment ring queue indices to be SMP safe. > > > Using a copy-API wouldn't be a problem for QEMU since the host and > > > guest are always running in lock-step. A copy API is actually needed > > > to deal with differing host/guest alignment and endianness. > > > > That seems a rather poor design choice, as many architectures don't have > > an atomic increment instruction. Oh well. > > Most have compare-and-swap or load-locked/store-conditional > instructions, though, which can be used to implement atomic increment. Yes, but your "hardware" implementation has to make sure it interacts with those properly. It's certainly possible to implement lockless lists without requiring atomic increment. Most high-end hardware manages it and that doesn't even have coherent DMA. Paul