On 09/12/2015 22:10, Andy Lutomirski wrote: > Can we please stop making kvmclock more complex? It's a beast right > now, and not in a good way. It's far too tangled with the vclock > machinery on both the host and guest sides, the pvclock stuff is not > well thought out (even in principle in an ABI sense), and it's never > been clear to my what problem exactly the kvmclock stuff is supposed > to solve.
It's supposed to solve the problem that: - not all hosts have a working TSC - even if they all do, virtual machines can be migrated (or saved/restored) to a host with a different TSC frequency - any MMIO- or PIO-based mechanism to access the current time is orders of magnitude slower than the TSC and less precise too. > I'm somewhat tempted to suggest that we delete kvmclock entirely and > start over. A correctly functioning KVM guest using TSC (i.e. > ignoring kvmclock entirely) seems to work rather more reliably and > considerably faster than a kvmclock guest. If all your hosts have a working TSC and you don't do migration or save/restore, that's a valid configuration. It's not a good default, however. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
