2016-10-17 15:20-0200, Marcelo Tosatti: > On Mon, Oct 17, 2016 at 04:50:09PM +0200, 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. > > Even if the guest can't detect the TSC difference (relative to realtime), > i suppose TSC should be advanced to account for the migration stopped > time (so that TSC appears to have incremented at a "constant rate"). I agree. >> 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. > > What is the use case for ART again? (need to catchup on that). It allows PCI devices to read a TSC-compatible timestamp and tag some data with it for the OS -- PTP uses it to avoid OS latency. I'm not sure if other devices use it right now. >> > 2) Savevm: It is not safe to use the TSC for wall clock timer >> > services. >> >> With constant TSC, we could argue that a shift to deep C-state happened >> and paused TSC, which is not a good behavior, but somewhat defensible. >> >> > By allowing savevm, you make a commitment to allow a feature >> > at the expense of not complying with the spec (specifically the " >> > the OS may use the TSC for wall clock timer services", because the >> > TSC stops relative to realtime for the duration of the savevm stop >> > window). >> >> Yep, we should at least guesstimate the TSC to allow the guest to resume >> with as small TSC-shift as possible and check that hosts were somewhat >> synchronized with UTC (or something we choose for time). > > There are two options for savevm: > > Option 1) Stop the TSC for savevm duration. > > Option 2) Advance TSC to match realtime (this is known to overflow Linux > timekeeping though). Thanks, I wondered why we use (1). Seems like something we'd like to fix. >> > But since Linux guests use kvmclock and Windows guests use Hyper-V >> > enlightenment, it should be fine to disable 2). >> > >> > There is a bug open for this, btw: >> > https://bugzilla.redhat.com/show_bug.cgi?id=1353073 >> >> These people should be happy with just live-migrations, so can't we just >> keep savevm forbidden? > > Don't see why. Perhaps savevm should be considered a "special type of > operation" that deviates from baremetal behaviour and that if > the user does savevm, then it knows TSC does not count "at a constant > rate" (so savevm breaks invariant tsc behaviour). Yes, it's an option, but some users are still going to complain; after which we'll point them to documentation and that leaves a bad impression on both sides. I don't like to expose something that is well defined and say that we redefined it. We could exposed something new (paravirtual), because the guest application needs to be paravirtualized to expect the change anyway. Migration can perform simple time synchronization by exchanging timestamps to ensure at least some level of "constant rate" illusion, which is harder to do with savevm. -- 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
