From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: Re: [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older compat types Date: Wed, 29 Aug 2012 16:43:39 +0200 Message-ID: <87mx1dep2c.fsf@elfo.mitica> References: <20120828191338.GE6223@otherpad.lan.raisama.net> <20120828213527.GB5817@redhat.com> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain Cc: Eduardo Habkost , gleb@redhat.com, kvm@vger.kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, Blue Swirl , Jan Kiszka , avi@redhat.com, Anthony Liguori To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:25580 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644Ab2H2Ooz (ORCPT ); Wed, 29 Aug 2012 10:44:55 -0400 In-Reply-To: <20120828213527.GB5817@redhat.com> (Michael S. Tsirkin's message of "Wed, 29 Aug 2012 00:35:28 +0300") Sender: kvm-owner@vger.kernel.org List-ID: "Michael S. Tsirkin" 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.)