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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> 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.

Oops, I'm sorry, I had a half-formed reply to this and
never finished/sent it:

The patch is in domain_cpuid, which gets called from
hvm_cpuid so shouldn't it affect HVMs also?  I hadn't thought
about dom0, but since dom0 never migrates, the result
should be the same (i.e. never a reason to override
the physical TSC invariant bit).

As for doing things in xc_cpuid_x86.c, I guess I don't
see this at all as a policy decision, only as mechanism
driven by other policy decisions (nomigrate and tsc_native).
Teaching all toolsets the subtleties of how to guarantee
correctness for a legal processor instruction doesn't
seem like a proper split between policy and mechanism
to me.

But, that said, I'm still not convinced my patch is the
right answer.  If possible (e.g. using the CPUID masking
feature Jan referred to), Xen should always hide the TSC
Invariant bit from all guests (OS's and apps) and only
expose it via pvcpuid or some other mechanism.
Otherwise an OS or app may make false assumptions
based on an architecturally-specified cpuid bit.
 
> > 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.

OK, I'll think about using pvcpuid instead of special MSRs.

> > 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?

I agree always-emulate becomes a degenerate case that
probably would rarely get used, but it might get used,
for example, to debug timing issues or test worst-case
(or post-migration) performance for high-frequency-rdtsc
guests/apps.

> > 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.

Conceptually, you are right.  But rather than add yet
another vm.cfg parameter and domctl, I'm thinking this
simpler modal approach to reduce complexity.

In fact, never-emulate is a degenerate case of pvrdtsc,
but for similar reasons I think a never-emulate option
should be kept around.

So the direction I'm heading is, instead of the three vm.cfg
parameters -- tsc_native, nomigrate, pvrdtsc -- there would
be a single quad-state parameter, tsc_mode:

0 = (default) Xen guarantees rdtsc correctness but uses
    emulation only when necessary
1 = rdtsc is always native
2 = rdtsc is always emulated
3 = (a) IF processor supports rdtscp instruction:
       rdtsc/p is native, Xen provides TSC_AUX and pvclock info
    (b) IF processor doesn't support rdtscp instruction:
       rdtsc/p is emulated (with degenerate TSC_AUX/pvclock info)

Thanks,
Dan


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