On Wed, Aug 29, 2012 at 09:09:16AM -0500, Anthony Liguori wrote:
> 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.
commit bfee7546df51c08e395dc8a7676a5c7f20186fee didn't enable pv_eoi, it
simple gave it a name.
>
> 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.
Reverting the commit won't do anything. The problem is at:
static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, const char *cpu_model)
{
[...]
plus_kvm_features = ~0; /* not supported bits will be filtered out later */
[...]
The bits are filtered out using GET_SUPPORTED_CPUID later.
For 1.2, we may temporarily change that ~0 into a hardcoded whitelist, so no
unknown feature will be enabled silently after a kernel upgrade.
--
Eduardo
--
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
