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: Juan Quintela
Subject: Re: [Qemu-devel] [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older compat types
Date: Wed, 29 Aug 2012 16:43:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> wrote:
> On Tue, Aug 28, 2012 at 04:13:38PM -0300, Eduardo Habkost wrote:
>> On Tue, Aug 28, 2012 at 08:43:52PM +0300, Michael S. Tsirkin wrote:
>> > 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
>> > 
>> 
>> What about users that are already running "qemu-1.1 -M pc-1.1" on a host
>> kernel that supports PV EOI already? They would get PV EOI disabled when
>> migrating to a destination running "qemu-1.2 -M pc-1.1".
>> 
>> (On the other hand, people running "qemu-1.1 -M pc-1.1" on a host kernel
>> supporting PV EOI already have migration broken, so there's not much we
>> can do for them)
>
> Exactly.
>
> Talked to Gleb, long term I think we should rework code to make
> it forward-compatible wrt adding new MSRs:
> - source gets list of MSRs to be migrated from KVM and simply sends
> them all

This is a bad idea, each time that we add a new MSR, we broke migration.
A better idea is just to _know_ what MSR's have been used by the guest,
and sent that ones.

> - send all MSRS in key/value format

Instead send all MSR's that have changed by its default value (for some
definition of default value).

> - destination gets list of MSRs to be migrated from KVM and
>   only restores the supported ones

it should be the other way around.  If source knows that an MSR is not
needed (it has never been read/writen/configured/... depends on the
MSR), then jsut dont' sent it.

> Too late for 1.2?

Yes.

ARM is trying to come with some fix for this (they have the CP15
registers, I think, that look a lot like MSR's.  I think that only
solution is what  I described here.

Current solution of explicitely list all of them is just a mass (TM).

Later, Juan.)



reply via email to

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