qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Brook
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Tue, 23 Mar 2010 00:49:41 +0000
User-agent: KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; )

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]