On Fri, Oct 09, 2009 at 05:48:31PM +0100, Jamie Lokier wrote: > Glauber Costa wrote: > > On Fri, Oct 09, 2009 at 11:06:41AM +0100, Jamie Lokier wrote: > > > Glauber Costa wrote: > > > > > It ensures the two models are compatible. Since they're the same device > > > > > from the point of view of the guest, there's no reason for them to have > > > > > different representations or to be incompatible. > > > > > > > > live migration between something that has in-kernel irqchip and > > > > something that has not is likely to be a completely untested > > > > thing. And this is the only reason we might think of it as the same > > > > device. I don't see any value in supporting this combination > > > > > > Not just live migration. ACPI sleep + savevm + loadvm + ACPI resume, > > > for example. > > Yes, but in this case too, I'd expect the irqchipness of qemu not to change. > > If I've just been sent an image produced by someone running KVM, and > my machine is not KVM-capable, or I cannot upgrade the KVM kernel > module because it's in use by other VMs (had this problem a few > times), there's no choice but to change the irqchipness. As gleb mentioned, requiring such a change to happen offline (across a reboot) is not that much of a pain. There are thousands of scenarios in which it will have to happen anyway, including major bumps in qemu version. -- 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
