From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [patch 2/2] target-i386: block migration and savevm if invariant tsc is exposed Date: Mon, 28 Apr 2014 21:06:42 +0200 Message-ID: <535EA6C2.4020103@redhat.com> References: <20140422191042.005048158@amt.cnet> <20140422191200.416302523@amt.cnet> <20140422203807.GJ3363@otherpad.lan.raisama.net> <20140422212759.GB28571@amt.cnet> <20140423011444.GL3363@otherpad.lan.raisama.net> <53597739.9000402@redhat.com> <20140424205720.GS3363@otherpad.lan.raisama.net> <535996EC.2080008@redhat.com> <20140424231834.GT3363@otherpad.lan.raisama.net> <535ACEB0.4020302@redhat.com> <20140428154652.GX3363@otherpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Igor Mammedov , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= To: Eduardo Habkost Return-path: In-Reply-To: <20140428154652.GX3363@otherpad.lan.raisama.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Il 28/04/2014 17:46, Eduardo Habkost ha scritto: >> So I couldn't indeed think of uses of "-cpu host" together with >> migration. But if you're sure there is none, block it in QEMU. >> There's no reason why this should be specific to libvirt. > > It's not that there are no useful use cases, it is that we simply can't > guarantee it will work because (by design) "-cpu host" enables features > QEMU doesn't know about (so it doesn't know if migration is safe or > not). And that's the main use case for "-cpu host". True, but in practice QEMU and KVM support is added in parallel, and we already have full support for Broadwell (IIRC) and are starting to add Skylake features. > So, what about doing the following on QEMU 2.1: > > * "-cpu host,migratable=yes": > * No invtsc > * Migration not blocked > * No feature flag unknown to QEMU will be enabled > * "-cpu host,migratable=no": > * invtsc enabled > * Unknown-to-QEMU features enabled > * Migration blocked > * "-cpu host": > * Same behavior as "-cpu host,migratable=yes" > * Release notes indicating that "-cpu host,migratable=no" is > required if the user doesn't care about migration and wants new > (unknown to QEMU) features to be available > > I was going to propose making "migratable=no" the default after a few > releases, as I expect the majority of existing users of "-cpu host" to > not care about migration. But I am not sure, because there's less harm > in _not_ getting new bleeding edge features enabled, and those users > (and management software) can start using "migratable=no" if they really > want the new unmigratable features. Makes sense. Basically "-cpu host,migratable=yes" is close to libvirt's host-model and Alex Graf's proposed "-cpu best". Should we call it "-cpu best" and drop migratability of "-cpu host"? Paolo