2016-10-17 18:24+0200, Paolo Bonzini: > On 17/10/2016 16:50, Radim Krčmář wrote: >> 2016-10-17 07:47-0200, Marcelo Tosatti: >>> On Fri, Oct 14, 2016 at 06:20:31PM -0300, Eduardo Habkost wrote: >>>> I have been wondering: should we allow live migration with the >>>> invtsc flag enabled, if TSC scaling is available on the >>>> destination? >>> >>> TSC scaling and invtsc flag, yes. >> >> Yes, if we have well synchronized time between hosts, then we might be >> able to migrate with a TSC shift that cannot be perceived by the guest. >> >> Unless the VM also has a migratable assigned PCI device that uses ART, >> because we have no protocol to update the setting of ART (in CPUID), so >> we should keep migration forbidden then. > > We don't publish the ART leaf at all, do we? Yes, it's a matter of time, though -- someone already asked for PTP in guests, so we'll have to either provide a paravirtual host<->guest time synchronization protocol that shares PTP from the host or let them use assigned devices ... >>> 1) Migration: to host with different TSC frequency. >> >> We shouldn't have done this even now when emulating anything newer than >> Pentium 4, because those CPUs have constant TSC, which only lacks the >> guarantee that it doesn't stop in deep C-states: > > Right, but: > >>> since Linux guests use kvmclock and Windows guests use Hyper-V >>> enlightenment, it should be fine to disable 2). > > ... and 1 too. Yes. We could stop exposing TSC then, because it should have no direct users -- kvmclock can work even if TSC is not in CPUID, because we paravirtualize it. > We should also blacklist the TSC deadline timer when invtsc is not > available. True. I was thinking that with Wanpeng's VMX preemption patches, we might not need the TSC nor paravirtual deadline timer, the because performance of LAPIC one-shot could be very similar. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
