qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older c


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older compat types
Date: Wed, 29 Aug 2012 09:09:16 -0500
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Gleb Natapov <address@hidden> writes:

> On Wed, Aug 29, 2012 at 08:36:30AM -0500, Anthony Liguori wrote:
>> "Michael S. Tsirkin" <address@hidden> 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 <address@hidden>
>> 
>> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]