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] [thread-next>] [day] [month] [year] [list]
Message-ID: <884aa233ef46d5209b2d1c92ce992f50a76bd656.camel@infradead.org>
Date:   Mon, 02 Oct 2023 09:33:49 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Dongli Zhang <dongli.zhang@...cle.com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     Joe Jin <joe.jin@...cle.com>, x86@...nel.org, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, pbonzini@...hat.com,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com
Subject: Re: [PATCH RFC 1/1] KVM: x86: add param to update master clock
 periodically

On Fri, 2023-09-29 at 13:15 -0700, Dongli Zhang wrote:
> 
> 
> We want more frequent KVM_REQ_MASTERCLOCK_UPDATE.
> 
> This is because:
> 
> 1. The vcpu->hv_clock (kvmclock) is based on its own mult/shift/equation.
> 
> 2. The raw monotonic (tsc_clocksource) uses different mult/shift/equation.
> 
> 3. As a result, given the same rdtsc, kvmclock and raw monotonic may return
> different results (this is expected because they have different
> mult/shift/equation).
> 
> 4. However, the base inĀ  kvmclock calculation (tsc_timestamp and system_time)
> are derived from raw monotonic clock (master clock)

That just seems wrong. I don't mean that you're incorrect; it seems
*morally* wrong.

In a system with X86_FEATURE_CONSTANT_TSC, why would KVM choose to use
a *different* mult/shift/equation (your #1) to convert TSC ticks to
nanoseconds than the host CLOCK_MONOTONIC_RAW does (your #2).

I understand that KVM can't track the host's CLOCK_MONOTONIC, as it's
adjusted by NTP. But CLOCK_MONOTONIC_RAW is supposed to be consistent.

Fix that, and the whole problem goes away, doesn't it?

What am I missing here, that means we can't do that?

Alternatively... with X86_FEATURE_CONSTANT_TSC, why do the sync at all?
If KVM wants to decide that the TSC runs at a different frequency to
the frequency that the host uses for CLOCK_MONOTONIC_RAW, why can't KVM
just *stick* to that?


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ