From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtsgG-0003EH-12 for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:13:16 -0400 Received: from [199.232.76.173] (port=58411 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtsgE-0003E9-ND for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:13:14 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtsgD-0005fT-18 for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:13:14 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:38191) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtsgC-0005fP-Og for qemu-devel@nongnu.org; Mon, 22 Mar 2010 21:13:12 -0400 Received: by gwb11 with SMTP id 11so1708379gwb.4 for ; Mon, 22 Mar 2010 18:13:12 -0700 (PDT) Message-ID: <4BA815A5.6070708@codemonkey.ws> Date: Mon, 22 Mar 2010 20:13:09 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups References: <201003221616.29962.paul@codesourcery.com> <4BA7BB8F.9070601@codemonkey.ws> <201003222101.00061.paul@codesourcery.com> In-Reply-To: <201003222101.00061.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Juan Quintela , qemu-devel@nongnu.org, "Michael S. Tsirkin" On 03/22/2010 04:00 PM, Paul Brook wrote: >> On 03/22/2010 11:16 AM, Paul Brook wrote: >> >>>> But look at the lguest virtio implement. We would definitely model a >>>> VirtIOBus if we implemented something like that in qemu. VirtIO really >>>> is designed to be a bus. >>>> >>> When you say "bus" you actually mean point-point connection, right[1]? >>> I don't see anything in virtio that allows arbitration of multiple >>> devices, or any particular need for one as it can be handled by the host >>> bus bindings. >>> >> Virtio itself doesn't define any type of bus operations but is designed >> to let it nicely fit into existing bus infrastructures. >> > My understanding is that virtio specifies transport agnostic queueing API for > passing buffers of data, and a small device specific config space. IMO a qemu > virtio bus should implement exactly that. The host bridge submits buffers, > and the device processes them. Allowing more than one device on this bus just > adds complication for no benefit. The only reason to have multiple devices on > a single bus is so that the can arbitrate a shared resource, and in this case > we have no resources to share. If a single host device wants to support > multiple virtio devices then it can create multiple busses. > > The purpose of the virtio bus is to expose the isolation between virtio device > and host bridge/binding to the user. This allows virtio devices to be > configured consistently without having to duplicate N hosts * M devices. > I think we ultimately agree. I think your point is that it's not technically a bus but it's convenient to model it that way. I definitely understand that point. Regards, Anthony Liguori