Re: [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older compat types

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

 



"Michael S. Tsirkin" <mst@xxxxxxxxxx> 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.)
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux