Re: [Xen-devel] HVMlite gains

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/03/2016 21:36, Andy Lutomirski wrote:
>
>>>   e) Can timing use RDTSC?
>> I don't understand this question in the context of the others.  RDTSC
>> has (as far as I can tell) always been advertised and available for
>> guest use.  RDTSCP is a different matter, and I have half-fixed that
>> brokenness; it should now work correctly in HVM guests.
>>
> These questions mostly came from me, and they weren't necessarily
> intended to make sense as a coherent whole :)  They were more of a
> random collection of things I was wondering about to varying extents.
>
> What I mean is:  if we point sched_clock at RDTSC and try to use the
> regular TSC timesource in a guest, will it work reasonably well,
> assuming that the underlying hardware supports it?  And, if the
> underlying hardware doesn't support it (e.g. not constant / invariant
> or no TSC offsetting available or similar), will the hypervisor tell
> the guest this fact via CPUID so that the standard guest clocksource
> code doesn't try to use a non-working TSC?

In principle yes, but it is rather more complicated than that.

By default, if you want a guest to be migrateable and you can't
guarantee that you will have hardware TSC scaling support on every
future destination, you cannot advertise the TSC as stable to the
guest.  We err on the side of caution and don't advertise invariance by
default.

In practice, if you are running on anything vaguely modern, the TSC will
be reliable between migrates.

What the migration protocol currently lacks is a mechanism to identify
"This VM was advertised invariant TSC at frequency $X when it was
booted".  There is nominally a "no migrate" flag which can be set, at
which point invariance will be advertised if the host is capable. 
However, there is no way for the toolstack to query this, so nothing in
the migrate code checks or acts upon it.

Windows have worked around this limitation with the Viridian spec,
whereby the hypervisor can provide the current TSC frequency, and
promises that it won't change until the next suspend/resume, at which
point the frequency will be resampled.

~Andrew

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