From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] pvcpuid: mask TSC invariant bit for various circumstances Date: Wed, 28 Oct 2009 07:16:13 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer , "Xen-Devel (E-mail)" List-Id: xen-devel@lists.xenproject.org On 27/10/2009 22:03, "Dan Magenheimer" wrote: > So after nack'ing you seem to be trying to convince me > that the patch is fine. What was your concern? Your patch only affected PV domUs; not dom0 nor HVM domUs. Further it was probably implemented in the wrong place -- this policy ought to be expressible in xc_cpuid_x86.c. This has the advantage it can be overridden in domain config files, just like any other CPUID bit. Only dom0 policy has to be hardcoded in the hypervisor itself. > Would you consider it a good solution for returning slightly > larger pieces of information, more than one bit but small > enough to fit in eax+ebx+ecx+edx? Very likely, yes. > A) Xen is responsible for correctness but will provide > native rdtsc performance whenever feasible; and If you can do this correctly, why would anyone use the always-emulate mode? > B) Xen is NOT responsible for correctness, rdtsc will > NEVER be emulated, but Xen will provide sufficient > information (via rdtscp and pvclock info) to ensure > an app can always synthesize a correct timestamp, > even across migration This seems like an extension which could be applicable to any TSC mode, rather than a new mode in its own right. -- Keir