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"... > 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. 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. -- PMM
