Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.

[Paolo Bonzini <pbonzini@redhat.com>]

Il 18/12/2012 15:56, Peter Maydell ha scritto:
> On 18 December 2012 14:36, Paolo Bonzini <pbonzini@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