From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51314) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6jVo-0007Ae-Db for qemu-devel@nongnu.org; Wed, 29 Aug 2012 10:44:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6jVn-00010D-A6 for qemu-devel@nongnu.org; Wed, 29 Aug 2012 10:44:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6jVn-000109-1W for qemu-devel@nongnu.org; Wed, 29 Aug 2012 10:44:55 -0400 From: Juan Quintela In-Reply-To: <20120828213527.GB5817@redhat.com> (Michael S. Tsirkin's message of "Wed, 29 Aug 2012 00:35:28 +0300") References: <20120828191338.GE6223@otherpad.lan.raisama.net> <20120828213527.GB5817@redhat.com> Date: Wed, 29 Aug 2012 16:43:39 +0200 Message-ID: <87mx1dep2c.fsf@elfo.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCHv4 3/4] cpuid: disable pv eoi for 1.1 and older compat types Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Eduardo Habkost , gleb@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, Blue Swirl , Jan Kiszka , avi@redhat.com, kvm@vger.kernel.org, Anthony Liguori "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.)