Gleb Natapov <gleb@xxxxxxxxxx> writes: > On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote: >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >> >> > In preparation for adding PV EOI support, disable PV EOI by default for >> > 1.1 and older machine types, to avoid CPUID changing during migration. >> > >> > PV EOI can still be enabled/disabled by specifying it explicitly. >> > Enable for 1.1 >> > -M pc-1.1 -cpu kvm64,+kvm_pv_eoi >> > Disable for 1.2 >> > -M pc-1.2 -cpu kvm64,-kvm_pv_eoi >> > >> > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> >> >> As best I can tell, we're papering over an ABI breakage in KVM. >> >> If an old QEMU attempts to do a live migration on a new kernel, >> migrating to an QEMU on a different box with an older kernel, it will >> fail because there is state that isn't being migrated. >> >> This ought to be fixed in the kernel by making these features >> whitelisted by userspace. >> > What do you mean. Userspace and only userspace decides what cpuid bits > will be seen by a guest. Currently userspace enables all PV cpuid bits > it finds. Right, I misunderstood from the commit message. I see now that the problem is that bfee7546df51c08e395dc8a7676a5c7f20186fee unconditionally enabled kvm_pv_eoi without taking into account migration support. I think for 1.2 we should simply revert the above commit and then we can restore it for 1.3 with proper support for migration. Regards, Anthony Liguori > > -- > Gleb. -- 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
