On Tue, 2020-12-01 at 08:19 -0800, Andy Lutomirski wrote: > > On Dec 1, 2020, at 6:01 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
