Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/22/2010 07:49 PM, Paul Brook wrote:
>> Solutions:
>> - VirtIOPCIBus and hang devices from there (anthony).  Why?  because
>>   this is a simulated pci bus, we can implement the features that we
>>   need (not full pci) in the three showed architectures.   We will have
>>   VirtIOPCIBLock everywhere, and its VirtIOPCIBus implmentation will
>>   hide the details.
>>      
> This is not how I understood Anthony's proposal.
>
> VirtIOPCIBus makes no sense. The whole reason we have this problem is because
> the VirtIO devices can not make any assumptions about the bus they are
> connected to.
>
> The key point is that we promote VirtIO devices to nodes in the device tree.
> i.e. VirtIODevice descends directly from DeviceState.
>
> Instead of trying to make a single polymorphic hybryd object, split into
> separate objects for the component parts.  Each host binding (PCI, syborg,
> s390, etc.) provides a single VirtIO bridge device. This includes a VirtIOBus,
> to which the VirtIODevice is attached.
>
> Most of the code and abstraction layers for this are already there.
> We just replace virtio_bind_device with VirtIOBus, add direct registration of
> VirtIODevice, and rip out all the crufty old device specific bits from virtio-
> pci.c.
>    

Right.  The only real challenge is dealing with legacy save/restore and 
command line syntax.  For save/restore, we can possibly have a dummy 
device that can split the VirtioPCI device state from the virtio device 
states and do the right thing.

I'm not sure what we should do for command line syntax.  We can keep 
-drive working as is.  Do we need to support -device based creation?  I 
don't think we've really considered what to do in a situation like this.

Regards,

Anthony Liguori

>
>    
>> - having multiple inheritance is "more natural" to virtio, then we have
>>    to change all the system to be able to allow multiple inherintance,
>>    even if it is more complex, and nothing else uses/needs it (mst).
>>      
> I'm not convinced multiple inheritance solves the real problem, much less that
> it is worthwhile.
>
> Paul
>
>
>