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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> On 27/10/2009 20:40, "Dan Magenheimer" 
> <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > The hacky part is my attempt for
> > the same cpuid bit (Invariant TSC) to have slightly
> > different interpretations depending on whether it is
> > physical (cpuid) or virtualized (pvcpuid)
> 
> How are you overloading it? According to your last patch you 
> would only make
> that bit visible to the guest when the TSC is invariant, and 
> will remain
> invariant (due to migration being disabled). That's within 
> native semantics of that bit, right?

Yes, the semantics are intended to be the same.  As long
as migration is disabled, it should work as intended.
I guess I was thinking into the next step of getting it
to work properly across certain "safe" migrations and
worrying that the pvcpuid-Invariant-TSC could change
dynamically whereas a physical cpuid-Invariant-TSC bit
would never change.

So after nack'ing you seem to be trying to convince me
that the patch is fine.  What was your concern?

> > So are you suggesting that the best mechanism for
> > "userland hypercalls" is special reserved cpuid leaves?
> 
> If you want to provide 'feature flags' and other such info to 
> the guest, it
> seems a pretty reasonable approach, since it already exists 
> and that's what
> it's intended for. There may be other things you want to do 
> for which it is
> not an appropriate solution, but everything so far seems 
> handleable via it.

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?

> > Also, any comments on the meat of my last reply?
> 
> Looked pretty complicated to me. Can't say as I fully understand it.

Yes, I wish it could be simpler.  It comes down to four
possible choices.  The first two are "always emulate
rdtsc" and "never emulate rdtsc" and these are already
implemented but nobody is very happy with either so
I'm looking for in-between solutions.  So I'm proposing
two more:

A) Xen is responsible for correctness but will provide
   native rdtsc performance whenever feasible; and
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

(A) would be a compromise I would propose for the default
for all VMs and (B) would be for intelligent apps that need
timestamps at a super-high-frequency and are willing
to change code and control their VM environment to
maximize performance.

Does that part make sense and sound reasonable?
Everything else is mechanism -- plus communication of
relevant data from Xen to an app -- to support these choices.

Dan

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