From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtiwL-0000q7-NH for qemu-devel@nongnu.org; Mon, 22 Mar 2010 10:49:13 -0400 Received: from [199.232.76.173] (port=46800 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtiwL-0000ps-Ab for qemu-devel@nongnu.org; Mon, 22 Mar 2010 10:49:13 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtiwJ-0005zX-RY for qemu-devel@nongnu.org; Mon, 22 Mar 2010 10:49:13 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:35456) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtiwJ-0005zQ-5M for qemu-devel@nongnu.org; Mon, 22 Mar 2010 10:49:11 -0400 Received: by fg-out-1718.google.com with SMTP id d23so398439fga.10 for ; Mon, 22 Mar 2010 07:49:09 -0700 (PDT) Message-ID: <4BA7835F.10906@codemonkey.ws> Date: Mon, 22 Mar 2010 09:49:03 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups References: <4BA6DB3F.7010702@codemonkey.ws> <201003221330.02217.paul@codesourcery.com> In-Reply-To: <201003221330.02217.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: "Michael S. Tsirkin" , qemu-devel@nongnu.org, Juan Quintela On 03/22/2010 08:30 AM, Paul Brook wrote: >> A VirtIOBlock device cannot be a VirtIODevice while being a >> VirtIOPCIProxy (proxy is a poor name, btw). >> >> It really ought to be: >> >> DeviceState -> VirtIODevice -> VirtIOBlock >> >> and: >> >> PCIDevice -> VirtIOPCI : implements VirtIOBus >> >> The interface between the VirtIODevice and VirtIOBus is the virtio >> transport. >> >> The main reason a separate bus is needed is the same reason it's needed >> in Linux. VirtIOBlock has to be tied to some bus. It cannot be tied to >> the PCI bus without having it be part of the implementation detail. >> Introducing another bus type fixes this (and it's what we do in the >> kernel). >> > Why does virtio need a device state and bus at all? > Because you need VirtIOBlock to have qdev properties that can be set. You also need VirtIOPCI to have separate qdev properties that can be set. > Can't it just be an internal implementation interface, which happens to be > used by all devices that happen to exposed a block device over a virtio > transport? > Theoretically, yes, but given the rest of the infrastructure's interaction with qdev, making it a device makes the most sense IMHO. > If you have a virtio bus then IMO the PCI bridge device should be independent > of the virtio device that is connected to it. > Yes, that's the point I'm making. IOW, there shouldn't be a "virtio-net-pci" device. Instead, there should be a "virtio-pci" device that implements a VirtIOBus and then we add a single VirtIODevice to it like "virtio-net". For something like MSI vector support, virtio-net really should have no knowledge of MSI-x. Instead, you should specific nvectors to virtio-pci and then virtio-pci should decide how to tie individual queue notifications to the amount of MSI vectors it has. I can't envision any reason why we would ever want to have two MSI vectors for a given queue. Regards, Anthony Liguori > Paul >