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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
