From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J15ie-0005zO-Qr for qemu-devel@nongnu.org; Sat, 08 Dec 2007 14:52:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J15ia-0005vo-55 for qemu-devel@nongnu.org; Sat, 08 Dec 2007 14:52:12 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J15ia-0005vk-0L for qemu-devel@nongnu.org; Sat, 08 Dec 2007 14:52:08 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J15iZ-000519-Eo for qemu-devel@nongnu.org; Sat, 08 Dec 2007 14:52:07 -0500 Received: by ug-out-1314.google.com with SMTP id m2so1159817uge for ; Sat, 08 Dec 2007 11:52:05 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 21:52:05 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device In-Reply-To: <200712081645.57284.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4755CC8C.6000001@us.ibm.com> <200712081322.39762.paul@codesourcery.com> <20071208140906.GA22712@shareable.org> <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 12/8/07, Paul Brook wrote: > 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. If we start adding locks for IO, could we use the same locking model more widely or make it generic so that it would support a SMP host as well?