linux-kernel - Re: [RFC 2/2] x86/kvmclock: Use host timekeeping.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ftkm7xpg.fsf@vitty.brq.redhat.com>
Date:   Tue, 24 Sep 2019 13:14:35 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Suleiman Souhlal <suleiman@...gle.com>
Cc:     John Stultz <john.stultz@...aro.org>, sboyd@...nel.org,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        rkrcmar@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
        Tomasz Figa <tfiga@...gle.com>
Subject: Re: [RFC 2/2] x86/kvmclock: Use host timekeeping.

Suleiman Souhlal <suleiman@...gle.com> writes:

> On Fri, Sep 20, 2019 at 10:33 PM Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>>
>> Suleiman Souhlal <suleiman@...gle.com> writes:
>>
>> > When CONFIG_KVMCLOCK_HOST_TIMEKEEPING is enabled, and the host
>> > supports it, update our timekeeping parameters to be the same as
>> > the host. This lets us have our time synchronized with the host's,
>> > even in the presence of host NTP or suspend.
>> >
>> > When enabled, kvmclock uses raw tsc instead of pvclock.
>> >
>> > When enabled, syscalls that can change time, such as settimeofday(2)
>> > or adj_timex(2) are disabled in the guest.
>> >
>> > Signed-off-by: Suleiman Souhlal <suleiman@...gle.com>
>> > ---
>> >  arch/x86/Kconfig                |   9 +++
>> >  arch/x86/include/asm/kvmclock.h |   2 +
>> >  arch/x86/kernel/kvmclock.c      | 127 +++++++++++++++++++++++++++++++-
>> >  kernel/time/timekeeping.c       |  21 ++++++
>> >  4 files changed, 155 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index 4195f44c6a09..37299377d9d7 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -837,6 +837,15 @@ config PARAVIRT_TIME_ACCOUNTING
>> >  config PARAVIRT_CLOCK
>> >       bool
>> >
>> > +config KVMCLOCK_HOST_TIMEKEEPING
>> > +     bool "kvmclock uses host timekeeping"
>> > +     depends on KVM_GUEST
>> > +     ---help---
>> > +       Select this option to make the guest use the same timekeeping
>> > +       parameters as the host. This means that time will be almost
>> > +       exactly the same between the two. Only works if the host uses "tsc"
>> > +       clocksource.
>> > +
>>
>> I'd also like to speak up against this config, it is confusing. In case
>> the goal is to come up with a TSC-based clock for guests which will
>> return the same as clock_gettime() on the host (or, is the goal to just
>> have the same reading for all guests on the host?) I'd suggest we create
>> a separate (from KVMCLOCK) clocksource (mirroring host timekeeper) and
>> guests will be free to pick the one they like.
>
> Fair enough. I'll do that in the next version of the patch.
>
> The goal is to have a guest clock that gives the same
> clock_gettime(CLOCK_MONOTONIC) as the host.
>

KVMCLOCK has lots of legacy derived from times when TSC synchronization
was not a given (I heard that this is still sometimes problematic with
multi-socket systems but oh well). If I was to design a new clock I'd
probably mirror Hyper-V's TSC page clocksource invalidating the page
when host timekeeper values are updated (and making guest spin).

The tricky part with this approach is probably tsc scaling/tsc
offsetting which is still going to be controlled by kvmclock (so the
guest has no option to read 'pure TSC'). As an alternative, you can make
kvmclock un-pluggable so when it's not enabled TSC frequency/offset can
remain intact. You can, of course, try to update timekeeper values to
match the new frequency/offset every time they change but rounding
errors may bite.

-- 
Vitaly