On Mon, Mar 22, 2010 at 09:49:03AM -0500, Anthony Liguori wrote: > 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.
Does this boil down to qdev wanting to be the 1st field in the structure, again? We can just lift that limitation. >> 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. No. OTOH whether we want a shared vector or a per-vq vector might depend on the device being used. > Regards, > > Anthony Liguori > >> Paul >>
