Re: [Xen-devel] [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation

[Olaf Hering <olaf@xxxxxxxxx>]

Am Mon, 11 Mar 2019 05:19:34 -0600
schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:

> >>> On 11.03.19 at 11:49, <olaf@xxxxxxxxx> wrote:  
> > I do not see how the HVM domU clock can be without drift if it does not
> > sync with an external source. It seems xenlinux based PV drivers lack
> > a clocksource, so they would better run ntp.  
> Yes indeed. But it still cannot be a requirement. There may be people
> wanting to fully isolate their systems.

They are free to isolate them. Still, there has to be a source to keep
time in sync. One of the involved dom0s can be declared as reference.
I'm not seeing how this change does affect the time within such domUs
in a significant way. Time will move forward at slightly different speed
when running on both hosts.

> Plus - is your change somehow limited to HVM guests? I can't seem to
> spot why that would be. And if it isn't, then leaving PV guests out of
> the discussion is simply wrong.

tsc_set_info exits early for non-HVM, so I think PV just does not have vtsc?

> Also I'm having trouble seeing how the connection to "drift" has come
> up all of the sudden. Your change is to deal with singular events
> (migration) aiui.

"drift" as in "TSC runs at different speed than reference clock"?
It is the migration/restore that enables emulation of TSC access.

> > Then the inaccuracy has to be handled, Xen can not know if cpu_khz is 
> > correct.
> > As said above, the observed range was 200, so this will be subtracted.  
> 
> This is what I consider wrong, because it results in
> 
>    tmp (initial)      |   tmp (result)
>    198                |   198
>    199                |   199
>    200                |   0
>    201                |   1
>    ...
>    398                |   198
>    399                |   199
>    400                |   0
>    401                |   1

Why does it become 0 here?

 
> I'd expect you to _cap_ at 200 instead. But of course the seemingly
> random 200 will itself need a much better reasoning, or at least a
> clear indication of the data base (number of different systems) that
> it was derived from. "Large number of hosts", after all, may mean 12
> to you and tens of thousands to me.

The formula reduces the calculated number by a constant. tmp would reach
zero on a 400MHz host. Assuming that still exists, the worst case is emulation
of TSC access. If the check would be (tmp > 200), tmp would become 1 khz
of difference. I think either '>' or '>=' would be fine on such system.


Olaf

Attachment: pgpZaD9AcehPm.pgp
Description: Digitale Signatur von OpenPGP

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel