[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c78ac6dc-8018-11c5-2b1e-c201448472fa@redhat.com>
Date: Thu, 3 Dec 2020 12:41:56 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org
Cc: Oliver Upton <oupton@...gle.com>, Ingo Molnar <mingo@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
open list <linux-kernel@...r.kernel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Jonathan Corbet <corbet@....net>,
Wanpeng Li <wanpengli@...cent.com>,
Borislav Petkov <bp@...en8.de>,
Jim Mattson <jmattson@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH 0/2] RFC: Precise TSC migration
On 01/12/20 20:35, Thomas Gleixner wrote:
>> This makes the random error in calculation of this value invariant
>> across vCPUS, and allows the guest to do kvmclock calculation in userspace
>> (vDSO) since kvmclock parameters are vCPU invariant.
>
> That's not the case today? OMG!
It's optional. If the host tells the guest that the host TSC is messed
up, kvmclock disables its vDSO implementation and falls back to the syscall.
Paolo
Powered by blists - more mailing lists