On Thu, Dec 13, 2012 at 08:51:30AM -0600, Anthony Liguori wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > > > Il 12/12/2012 18:58, Peter Maydell ha scritto: > >> It should be equally > >> valid to just use the PCI transport plugged into a VirtioDevice, > >> both of which were created by the user with -device [and for > >> new transports, separate transport and backend should be the > >> standard]. That means the virtio-bus interface needs a way for > >> the backend to announce to the transport what it is so that > >> the PCI transport can set the right PCI IDs. > > > > There is such an interface (the device_id, aka VIRTIO_ID_*). Then > > virtio-pci needs a mapping from the device_id to the (default) > > vendor_id/device_id/class tuple. > > Why? > > I think it's perfectly fine to have to specify a device ID for > virtio-pci. > > The way virtio-pci is designed is such that every device that uses > virtio-pci ends up looking like an independent PCI device. > > We should always have virtio-blk-pci, virtio-net-pci, etc. The goal of > this refactoring should not be to eliminate that. > > But these devices should be trivial to implement and modelled in a sane > way. > > I don't think we should be trying to solve the problem of making > virtio-pci "easy to use". Why would you say: > > -device virtio-pci,id=foo -device virtio-blk,bus=foo > > When you can just say: > > -device virtio-pci-blk > > I think we're optimizing for the wrong thing here... > > Regards, > > Anthony Liguori > > > > > Paolo
I agree. What I mean is this: virtio has device IDs. These are not pci specific and are defined in linux/virtio_ids.h Now it looks like pci device IDs of virtio devices are pci id = 0x1000 + virtio device ID; so let's pull virtio_ids.h from linux and write a macro that does + 0x1000 instead of hard-coding values. Makes sense? -- MST
