Re: [PATCH] xen: preserve native TSC speed during migration between identical hosts

From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Wei Liu <wei.liu2@citrix.com>,
	xen-devel@lists.xen.org, Ian Jackson <ian.jackson@eu.citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] xen: preserve native TSC speed during migration between identical hosts
Date: Tue, 30 May 2017 10:28:48 -0400	[thread overview]
Message-ID: <20170530142848.GJ7434@char.us.oracle.com> (raw)
In-Reply-To: <20170530092705.GC26792@aepfle.de>

On Tue, May 30, 2017 at 11:27:05AM +0200, Olaf Hering wrote:
> On Wed, May 24, Konrad Rzeszutek Wilk wrote:
> 
> > Is there some form of tests that they can run to verify and test
> > that this is safe? Or perhaps this is something that is based on the kernel
> > versions? Like 4.11 are safe, but 3.18 is not?
> 
> I'm not sure why you are asking for specific kernel versions.

Because a blanket statement saying: "Use that for everything" (including
Windows OSes) makes me nervous that some other OSes may not be
comfortable with this or would not work.

But it is unrealistic to ask you to test _every_ single OS or kernel
to verify this. And hence providing a test-case for folks to run/test
can help them with evaluating this.

> 
> 
> But the test is simply to boot a HVM domU with 'tsc_mode=native' and
> migrate it to a similar dom0. This fails with 3.12 and 4.4 based domU
> kernels, with xen-4.7 as dom0. This pretty much ruins the plan.
> 
> So far I have not investigated why the domU on the remote side does not
> get any cpu time, or why it makes no progress. But in the end the I
> think only a hardware upgrade to TSC-scaling capable CPUs will avoid the
> performance penalty due to the TSC emulation.
> I do not have access to such hardware to verify it.
> 
> 
> Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel