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

[Michael S. Tsirkin]

On Mon, Mar 22, 2010 at 08:16:01PM -0500, Anthony Liguori wrote:
> 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

If we need to change command line because of an implementation
change, IMO something is wrong with the design.
Users shouldn't care about non-existent virtio bus.

>>
>>    
>>> - 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
>>
>>
>>