Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes: >> On Oct 3, 2018, at 2:22 AM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote: >> >> Andy Lutomirski <luto@xxxxxxxxxx> writes: >> >>> Hi Vitaly, Paolo, Radim, etc., >>> >> The notification you're talking about exists, it is called >> Reenligntenment, see 0092e4346f49 "x86/kvm: Support Hyper-V >> reenlightenment"). When TSC page changes (and this only happens when L1 >> is migrated to a different host with a different TSC frequency and TSC >> scaling is not supported by the CPU) we receive an interrupt in L1 (at >> this moment all TSC accesses are emulated which guarantees the >> correctness of the readings), pause all L2 guests, update their kvmclock >> structures with new data (we already know the new TSC frequency) and >> then tell L0 that we're done and it can stop emulating TSC accesses. > > That’s delightful! Does the emulation magic also work for L1 user > mode? As far as I understand - yes, all rdtsc* calls will trap into L0. > If so, couldn’t we drop the HyperV vclock entirely and just > fold the adjustment into the core timekeeping data? (Preferably the > actual core data, which would require core changes, but it could > plausibly be done in arch code, too.) Not all Hyper-V hosts support reenlightenment notifications (and, if I'm not mistaken, you need to enable nesting for the VM to get the feature - and most VMs don't have this) so I think we'll have to keep Hyper-V vclock for the time being. -- Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
