"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
