Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC scaling is supported by hardware

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Wei Huang [mailto:wei.huang2@xxxxxxx]
> Subject: Re: [Xen-devel] [PATCH] svm: Do not intercept RDTCS(P) when TSC 
> scaling is supported by
> hardware
> 
> >>>
> >>> When running in TSC_MODE_ALWAYS_EMULATE mode on processors that support
> >>> TSC scaling we don't need to intercept RDTSC/RDTSCP instructions.
> >>>
> >>> Signed-off-by: Boris Ostrovsky<boris.ostrovsky@xxxxxxx>
> >>> Acked-by: Wei Huang<wei.huang2@xxxxxxx>
> >>> Tested-by: Wei Huang<wei.huang2@xxxxxxx>
> >> Worth an ack/nack from Dan M I'd say. He'll probably have some comment 
> >> about
> >> possible cross-CPU TSC skew.
> > Provided the hypervisor writes the "TSC-scale-register" with the same
> > value when any vcpu for any guest is scheduled, I don't think
> > there is any cross-CPU TSC skew.
> >
> > But my recollection is that I had a concern that, to work properly
> > after migration, TSC scaling might need to implement:
> >
> >     ((B + cur_tsc) * scale ) + A
> Hi Dan,
> 
> Thanks for your review. I tried to interpret this formula as the following:
> 
> cur_tsc: Guest TSC before migration
> B: time elapsed (overhead) during migration
> scale: ratio of guest frequency/target host frequency
> A: target host TSC

Hi Wei --

I have to admit I don't remember the details of the problem anymore
and can't mentally reproduce it right now.  If TSC scaling is deployed
(on Xen... I imagine it was designed to accommodate VMware)
and works as well as emulation but faster, great!  I just would hope
that there is a great deal of testing done before it becomes
the default because if problems do occur, they will be extremely
difficult to track down.

>> Without the rest of the implementation in the hypervisor
>> and tools, it's hard to determine whether my concern is valid
>> or not.
> If my interpretation above is correct, doesn't emulated TSC have the 
> same problem of B == 0?

That may be true.  But if the emulation code for HVM is broken and
must be fixed, that's a much easier change than a change to a
hardware instruction.

> Hardware TSC scaling uses 8.32 format: 8 bits for integer part and 32
> bits for fraction. Is it enough for the precision from your experience?
> The details of TSC scaling spec can be found on page 554 of
> http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf.

I didn't write the emulation scaling code for HVM... if it uses
a 32-bit scale factor, your 8+32 should be more precise.  If
it uses a 64-bit multiplier, it will be less precise.  OTOH,
the "how many TSC ticks per second" code in Xen may not be
precise anyway.

Keir/Jan, I still think it would be a good idea to implement a
global boot-time "never trust the hardware TSC" option (default off)
which would result in all guests always emulating TSC.
At least this would be a "baseline" and any problems with
it are due to hypervisor bugs.

Dan

P.S. About to be away from email for a few days.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel