search for: masterclock

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

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

...; https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > > > Is it correct, or am I missing some subtlety? > > > > The master clock, when initialized, has a pair > > > > masterclockvalues=(TSC value, time-of-day data). > > > > When updating the guest clock, we only update relative to (TSC value) > > that was read on masterclock initialization. > > I don't see the problem. The masterclock data is updated here: > > host_tsc_clocksource =...

...; https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > > > Is it correct, or am I missing some subtlety? > > > > The master clock, when initialized, has a pair > > > > masterclockvalues=(TSC value, time-of-day data). > > > > When updating the guest clock, we only update relative to (TSC value) > > that was read on masterclock initialization. > > I don't see the problem. The masterclock data is updated here: > > host_tsc_clocksource =...

...So far, > I've come up with this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > Is it correct, or am I missing some subtlety? The master clock, when initialized, has a pair masterclockvalues=(TSC value, time-of-day data). When updating the guest clock, we only update relative to (TSC value) that was read on masterclock initialization. See the following comment on x86.c: /* * * Assuming a stable TSC across physical CPUS, and a stable TSC * across virtual CPUs, the following...

...So far, > I've come up with this patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > Is it correct, or am I missing some subtlety? The master clock, when initialized, has a pair masterclockvalues=(TSC value, time-of-day data). When updating the guest clock, we only update relative to (TSC value) that was read on masterclock initialization. See the following comment on x86.c: /* * * Assuming a stable TSC across physical CPUS, and a stable TSC * across virtual CPUs, the following...

...znetsov wrote: >>>> 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? >>> >>> No, and it is not the hardware you have to worry about (mostly)...

...znetsov wrote: >>>> 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? >>> >>> No, and it is not the hardware you have to worry about (mostly)...

....git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > > > > > > > Is it correct, or am I missing some subtlety? > > > > > > > > The master clock, when initialized, has a pair > > > > > > > > masterclockvalues=(TSC value, time-of-day data). > > > > > > > > When updating the guest clock, we only update relative to (TSC value) > > > > that was read on masterclock initialization. > > > > > > I don't see the problem. The masterclock data is upd...

....git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > > > > > > > Is it correct, or am I missing some subtlety? > > > > > > > > The master clock, when initialized, has a pair > > > > > > > > masterclockvalues=(TSC value, time-of-day data). > > > > > > > > When updating the guest clock, we only update relative to (TSC value) > > > > that was read on masterclock initialization. > > > > > > I don't see the problem. The masterclock data is upd...

...04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: >> 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? > > No, and it is not the hardware you have to worry about (mostly), it is > the frigging PoS fi...

...04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: >> 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? > > No, and it is not the hardware you have to worry about (mostly), it is > the frigging PoS fi...

...isn't used > > > for VM timing as such -- it's used for the IOCTL interfaces for > > > updating the time offset. So can you explain how my patch is > > > incorrect? > > > > ktime_get_boot_ns() has frequency correction applied, while > > reading masterclock + TSC offset does not. > > > > So the clock reads differ. > > > > Ah, okay, I finally think I see what's going on. In the kvmclock data > exposed to the guest, tsc_shift and tsc_to_system_mul come from > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now...

...isn't used > > > for VM timing as such -- it's used for the IOCTL interfaces for > > > updating the time offset. So can you explain how my patch is > > > incorrect? > > > > ktime_get_boot_ns() has frequency correction applied, while > > reading masterclock + TSC offset does not. > > > > So the clock reads differ. > > > > Ah, okay, I finally think I see what's going on. In the kvmclock data > exposed to the guest, tsc_shift and tsc_to_system_mul come from > tgt_tsc_khz, whereas master_kernel_ns and master_cycle_now...

...this patch: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > Is it correct, or am I missing some subtlety? > > The master clock, when initialized, has a pair > > masterclockvalues=(TSC value, time-of-day data). > > When updating the guest clock, we only update relative to (TSC value) > that was read on masterclock initialization. I don't see the problem. The masterclock data is updated here: host_tsc_clocksource = kvm_get_time_and_clockread(...

...cm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf > > > > > > > > Is it correct, or am I missing some subtlety? > > > > > > The master clock, when initialized, has a pair > > > > > > masterclockvalues=(TSC value, time-of-day data). > > > > > > When updating the guest clock, we only update relative to (TSC value) > > > that was read on masterclock initialization. > > > > I don't see the problem. The masterclock data is updated here: > > >...

...velous proof of this, which this margin is too narrow to contain" :-) There is a very long history of different (hardware) issues Marcelo was fighting with and the current code is the survived Frankenstein. E.g. it is very, very unclear what "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctly to > the L2 guest when L0 is hyperv. KVM cou...

...velous proof of this, which this margin is too narrow to contain" :-) There is a very long history of different (hardware) issues Marcelo was fighting with and the current code is the survived Frankenstein. E.g. it is very, very unclear what "catchup", "always catchup" and masterclock-less mode in general are and if we still need them. That said I'm all for simplification. I'm not sure if we still need to care about buggy hardware though. > > And I don't see how it's even possible to pass kvmclock correctly to > the L2 guest when L0 is hyperv. KVM cou...

On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: > 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? No, and it is not the hardware you have to worry about (mostly), it is the frigging PoS firmware people put on it...

On 04/10/2018 09:54, Vitaly Kuznetsov wrote: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). Not if you want to migrate to pre-Skylake systems. > - 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? No. :( We still get reports whenever we break 2007-2008 hardware. Paolo