[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874kl5hbgp.fsf@nanos.tec.linutronix.de>
Date: Tue, 01 Dec 2020 15:01:26 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Marcelo Tosatti <mtosatti@...hat.com>,
Maxim Levitsky <mlevitsk@...hat.com>
Cc: kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Oliver Upton <oupton@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Sean Christopherson <sean.j.christopherson@...el.com>,
open list <linux-kernel@...r.kernel.org>,
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 Mon, Nov 30 2020 at 16:16, Marcelo Tosatti wrote:
> Not really. The synchronization logic tries to sync TSCs during
> BIOS boot (and CPU hotplug), because the TSC values are loaded
> sequentially, say:
>
> CPU realtime TSC val
> vcpu0 0 usec 0
> vcpu1 100 usec 0
> vcpu2 200 usec 0
That's nonsense, really.
> And we'd like to see all vcpus to read the same value at all times.
Providing guests with a synchronized and stable TSC on a host with a
synchronized and stable TSC is trivial.
Write the _same_ TSC offset to _all_ vcpu control structs and be done
with it. It's not rocket science.
The guest TSC read is:
hostTSC + vcpu_offset
So if the host TSC is synchronized then the guest TSCs are synchronized
as well.
If the host TSC is not synchronized, then don't even try.
Thanks,
tglx
Powered by blists - more mailing lists