Il 18/12/2012 15:56, Peter Maydell ha scritto: > On 18 December 2012 14:36, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Yes, that's true. And you're basically using virtio as the pluggable >> discoverable bus, which is actually a pretty good idea. >> >> However, what you are doing is very similar to what virtio-s390 does, >> and it manages to do it just fine with the existing virtio.c >> infrastructure. The only difference is that you have a 1:1 relationship >> between virtio-mmio "slots" described by the board and virtio-mmio >> devices added by the user. > > Also it looks like the board model and the 'bridge' and the transport > implementation are all collaborating to get the virtio memory sorted > out, rather than it just being "instantiate a bridge here"...
But s390 is weird. :) >> True, it is not pure qdev, but it is much simpler and doesn't require >> convincing grumpy maintainers. :) > > I'm not actually personally all that attached to this design -- it's just > trying to implement a suggestion by Anthony. Yes, and I agree FWIW. > It does seem frankly bizarre that adding a new transport requires > knowing about all the backends (notice how s390-virtio-bus.c has > to register types for each backend). The kernel gets the transport > vs backend separation much cleaner and it was much easier to > add the virtio support there. Yes, I agree. However, to some extent it's unavoidable. For example, the PCI transport needs to know the class id for each backend. You may have a single virtio-pci device types, or separate types for virtio-blk/net/scsi-pci, but it's true anyway. Paolo
