Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state

[Avi Kivity]

On 01/18/2011 05:50 PM, Anthony Liguori wrote:
> > This design is in conflict with the requirement to attach KVM-assisted
> > devices also to their home bus, e.g. an assigned PCI device to the PCI
> > bus. We don't support multi-homed qdev devices.
>
> The bus topology reflects how I/O flows in and out of a device.  We do 
> not model a perfect PC bus architecture and I don't think we ever 
> intend to.  Instead, we model a functional architecture.

A KVM bus is far from a function architecture.  It simply departs from 
both what a real PC looks like, and what a KVM PC looks like to a guest, 
for no reason except to force a particular object model.

It's completely artificial.  If kvm were not behind the kernel/user 
interface, and an unchangeable ABI, we'd refactor it.  However, we can't 
refactor it, and you're trying to warp the device model to adapt to this 
design problem instead of working around it.  You're elevating a kink 
into an architectural feature.

> I/O from an assigned device does not flow through the emulated PCI 
> bus.  Therefore, it does not belong on the emulated PCI bus.

Yes it does.  Config space and some mmio flows through qemu and the 
emulated PCI bus.  So do things like hotplug/hotunplug.


> Assigned devices need to interact with the emulated PCI bus, but they 
> shouldn't be children of it.

What's the difference, from the guest point of view, from an assigned 
RTL8139 card, and an emulated RTL8139 card?

If you believe there is no difference, what better way to model this 
than implement them the same way using the same interfaces?

--
error compiling committee.c: too many arguments to function