Re: [Xen-devel] HVMlite gains

[Andy Lutomirski <luto@xxxxxxxxxxxxxx>]

On Tue, Mar 15, 2016 at 2:50 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

By "reliable" do you mean monotonic and not horribly jumpy?  I thought
there was no shipping hardware with TSC scaling.

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

That's simpler and maybe even better than the pvclock design, at least
as implemented by KVM.  Sigh.

--Andy

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