From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58964)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1WlEUC-0005vc-Na
	for qemu-devel@nongnu.org; Fri, 16 May 2014 05:31:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1WlEU6-0007rs-JZ
	for qemu-devel@nongnu.org; Fri, 16 May 2014 05:31:28 -0400
Received: from mx1.redhat.com ([209.132.183.28]:6213)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1WlEU6-0007rl-CN
	for qemu-devel@nongnu.org; Fri, 16 May 2014 05:31:22 -0400
Date: Fri, 16 May 2014 06:31:06 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20140516093106.GD25693@amt.cnet>
References: <1400095810-27684-1-git-send-email-ehabkost@redhat.com>
	<1400095810-27684-18-git-send-email-ehabkost@redhat.com>
	<87y4y38ce0.fsf@elfo.mitica>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y4y38ce0.fsf@elfo.mitica>
Subject: Re: [Qemu-devel] [PATCH RESEND v4 17/18] target-i386: block
 migration and savevm if invariant tsc is exposed
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juan Quintela <quintela@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>, Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>, qemu-devel@nongnu.org

On Thu, May 15, 2014 at 02:17:11PM +0200, Juan Quintela wrote:
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> > From: Marcelo Tosatti <mtosatti@redhat.com>
> >
> > Invariant TSC documentation mentions that "invariant TSC will run at a
> > constant rate in all ACPI P-, C-. and T-states".
> >
> > This is not the case if migration to a host with different TSC frequency
> > is allowed, or if savevm is performed. So block migration/savevm.
> >
> > Cc: Juan Quintela <quintela@redhat.com>
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> > Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> 
> Reviewed-by: Juan Quintela <quintela@redhat.com>
> 
> I don't have a better suggestion.  Really we could allow migration to
> identical machines, but I assume that there is not a way to read the tsc
> frequency?
> (Althought reading the model name/numbers could be enough?)

Even if migration to identical machine is performed, you would have 
to perform timing of downtime to compensate.

> I.e. Add a subsection that includes the cpu model name, or whatever we
> can have to identify the host cpu?

"On processors with invariant TSC support, the OS may use the TSC for
wall clock timer services (instead of ACPI or HPET timers)."