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: Fri, 25 Apr 2014 00:57:48 +0200 Message-ID: <535996EC.2080008@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, qemu-devel@nongnu.org, Igor Mammedov , =?ISO-8859-1?Q?Andreas_F=E4rber?= To: Eduardo Habkost Return-path: Received: from mail-ee0-f50.google.com ([74.125.83.50]:39699 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754663AbaDXW5u (ORCPT ); Thu, 24 Apr 2014 18:57:50 -0400 Received: by mail-ee0-f50.google.com with SMTP id c13so2336487eek.9 for ; Thu, 24 Apr 2014 15:57:49 -0700 (PDT) In-Reply-To: <20140424205720.GS3363@otherpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: Il 24/04/2014 22:57, Eduardo Habkost ha scritto: > On Thu, Apr 24, 2014 at 04:42:33PM -0400, Paolo Bonzini wrote: >> Il 22/04/2014 21:14, Eduardo Habkost ha scritto: >>> Not for "-cpu host". If somebody needs migration to work, they shouldn't >>> be using "-cpu host" anyway (I don't know if you have seen the other >>> comments in my message?). >> >> I'm not entirely sure. If you have hosts with exactly identical >> chipsets, "-cpu host" migration will in all likelihood work. >> Marcelo's approach is safer. > > If that didn't break other use cases, I would agree. > > But "-cpu host" today covers two use cases: 1) enabling everything that > can be enabled, even if it breaks migration; 2) enabling all stuff that > can be safely enabled without breaking migration. What does it enable *now* that breaks migration? > Now we can't do both at the same time[1]. > > (1) is important for management software; > (2) works only if you are lucky. Or if you plan ahead. With additional logic even invariant TSC in principle can be made to work across migration if the host clocks are synchronized well enough (PTP accuracy is in the 100-1000 TSC ticks range). > Why would it make sense to break (1) to try make (2) work? > > [1] I would even argue that we never did both at the same time."-cpu > host" depends on host hardware capabilities, host kernel capabilities, > and host QEMU version (we never took care of keeping guest ABI with > "-cpu host"). If migration did work, it was never supposed to. I think this is where I disagree. Migration of the PMU is one thing that obviously was done with "-cpu host" in mind. Paolo