WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] pvcpuid: mask TSC invariant bit for various circ

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] pvcpuid: mask TSC invariant bit for various circumstances
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 28 Oct 2009 07:16:13 +0000
Cc:
Delivery-date: Wed, 28 Oct 2009 00:16:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <bae0b274-34e9-48f8-b689-440f61714909@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcpXUWE+4/IkPtSOR1axJsfVkqcmhAATSar3
Thread-topic: [Xen-devel] [PATCH] pvcpuid: mask TSC invariant bit for various circumstances
User-agent: Microsoft-Entourage/12.20.0.090605
On 27/10/2009 22:03, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>