Marcelo Tosatti <mtosa...@redhat.com> 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). - 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? -- Vitaly _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
