[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcpXUWE+4/IkPtSOR1axJsfVkqcmhAATSar3
  • Thread-topic: [Xen-devel] [PATCH] pvcpuid: mask TSC invariant bit for various circumstances

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.