linux-kernel - Re: [PATCH 0/2] RFC: Precise TSC migration

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: <0d8c407cc81bedc9a344646978c857d26f2b5be8.camel@redhat.com>
Date:   Thu, 03 Dec 2020 13:57:04 +0200
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Andy Lutomirski <luto@...capital.net>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Marcelo Tosatti <mtosatti@...hat.com>, 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 Tue, 2020-12-01 at 08:19 -0800, Andy Lutomirski wrote:
> > On Dec 1, 2020, at 6:01 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > 
> > 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.
> 
> This reminds me: if you’re adding a new kvm feature that tells the guest that the TSC works well, could you perhaps only have one structure for all vCPUs in the same guest?

I won't mind doing this, but this might be too much work for
too little gain.

IMHO, modern hosts don't need the kvmclock in the first place,
and should just expose the TSC to the guest 
together with the invtsc bit.

Best regards,
	Maxim Levitsky

> 
> > Thanks,
> > 
> >        tglx