On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: > Marcelo Tosatti <mtosatti@xxxxxxxxxx> writes: > > > On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: > >> > >> There is a very long history of different (hardware) issues Marcelo was > >> fighting with and the current code is the survived Frankenstein. > > > > Right, the code has to handle different TSC modes. > > > >> E.g. it > >> is very, very unclear what "catchup", "always catchup" and > >> masterclock-less mode in general are and if we still need them. > > > > Catchup means handling exposed (to guest) TSC frequency smaller than > > HW TSC frequency. > > > > That is "frankenstein" code, could be removed. > > > >> That said I'm all for simplification. I'm not sure if we still need to > >> care about buggy hardware though. > > > > What simplification is that again? > > > > I was hoping to hear this from you :-) If I am to suggest how we can > move forward I'd propose: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). In that case just use TSC clocksource on the guest directly: i am writing code for that now (its faster than pvclock syscall). > - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page > clocksource is a single page for the whole VM, not a per-cpu thing. Can > we think that all the buggy hardware is already gone? As Peter mentioned, non sync TSC hardware might exist in the future. And older hardware must be supported. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
