On 12/05/2011 03:29 PM, Jan Kiszka wrote: > On 2011-12-05 14:14, Avi Kivity wrote: > > On 12/05/2011 02:47 PM, Jan Kiszka wrote: > >>> > >>> (the memory API added unstable names, hopefully the QOM can take over > >>> the stable ones and we'll have a good way to denote the unstable ones). > >>> > >> > >> OK, maybe - or likely - we should make those device models have the same > >> names in QOM once instantiated. But I'm still convinced they should > >> remain separated models in contrast to a single model with a property. > > > > What do you mean by separate models? You share all the code you can, > > and don't share the code you can't. To me, single model == single name. > > But different configuration. Right, just like IDE with different backends. > > > >> The kvm ioapic, e.g., requires an additional property (gsi_base) that is > >> meaningless for user space devices. And its interrupts have to be > >> wired&configured differently at board model level. So, from the QEMU > >> POV, it is a very different device. Just the guest does not notice. > > > > It's like qcow2 and raw/native IO are wire differently, or virtio-net > > and vhost-net. But it's the same IDE device or virtio NIC. > > That would mean introducing a backend/frontend concept for irqchips. We could do it, have one ioapic model with ioapic_ops->eoi_broadcast(). Most of the interfaces already dispatch dynamically (qdev gpio/irq) so there wouldn't be much more there. To me, how it's actually implemented is not important. What is important is that save/restore, the monitor, and the guest don't notice any changes. -- 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