From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J17l8-0005TC-0U for qemu-devel@nongnu.org; Sat, 08 Dec 2007 17:02:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J17l7-0005T0-J0 for qemu-devel@nongnu.org; Sat, 08 Dec 2007 17:02:53 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J17l7-0005Sx-DB for qemu-devel@nongnu.org; Sat, 08 Dec 2007 17:02:53 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J17l7-0000KS-1U for qemu-devel@nongnu.org; Sat, 08 Dec 2007 17:02:53 -0500 Received: by an-out-0708.google.com with SMTP id b38so554225ana for ; Sat, 08 Dec 2007 14:02:52 -0800 (PST) Message-ID: <475B1488.5040200@codemonkey.ws> Date: Sat, 08 Dec 2007 16:02:48 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/3] virtio network device References: <4755CC8C.6000001@us.ibm.com> <200712081322.39762.paul@codesourcery.com> <20071208140906.GA22712@shareable.org> <200712081645.57284.paul@codesourcery.com> <20071208215510.GB30486@shareable.org> In-Reply-To: <20071208215510.GB30486@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 , Paul Brook 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. >> > > I'm inclined to agree that a lockless structure (including not using > an atomic op) for the most commonly used paths, such as appending to a > ring, would be better. It increases the potential portability for > emulation/virtualisation across all architectures now and in the > future, and it would almost certainly perform better on architectures > other than x86. > > However, occasionally you need to enter the host for synchronisation. > E.g. when a ring is empty/full. > > In that case, sometimes using atomic ops in the way that futexes are > used in Linux/Glibc can optimise the details of those transitions, but > it would be best if they were optional optimisations, for > cross-platform, cross-architure portability. > > There's a particularly awkward problem when taking an x86 atomic op in > the guest, and generating code on the non-x86 host which doesn't have > any equivalent op. What's the right thing to do? > > Since virtio is driven by virtualisation projects rather than > emulation, is it possible this hasn't been thought of at all, making > virtio unusable for cross-architecture emulation? That would be > really unfortunate. > virtio has been designed for virtualization, yes. There aren't really restrictions that prevent it's use when doing cross-architecture emulation (yet) with QEMU. If QEMU ever got true SMP support, then virtio would not work as it requires 16-bit atomic writes which AFAIK is not possible on a number of non-x86 architectures. Regards, Anthony Liguori > -- Jamie > > > >