On Fri, 2024-04-19 at 16:49 +0100, Paul Durrant wrote:
On 18/04/2024 20:34, David Woodhouse wrote:
From: David Woodhouse dwmw@amazon.co.uk
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully inadequate. It ignores TSC scaling, and ignores the fact that the host TSC may differ from one host to the next (and in fact because of the way the kernel calibrates it, it generally differs from one boot to the next even on the same hardware).
Add KVM_VCPU_TSC_SCALE to extract the actual scale ratio and frac_bits, and attempt to document the *awful* process that we're requiring userspace to follow to merely preserve the TSC across migration.
I may have thrown up in my mouth a little when writing that documentation. It's an awful API. If we do this, we should be ashamed of ourselves. (I also haven't tested the documented process yet).
Let's use Simon's KVM_VCPU_TSC_VALUE instead. https://lore.kernel.org/all/20230202165950.483430-1-sveith@amazon.de/
Oops, I meant to change that commit message. I've changed my mind, as KVM_VCPU_TSC_VALUE sets the TSC using the KVM clock as a reference... which is utterly backwards, since the KVM clock is *defined* in terms of the TSC.
Will do so before posting it again.
May also include the "loop over KVM_GET_CLOCK until tai_offset didn't change" part to fix the leap seconbd problem.
I think we do need to implement a better way to get { TAI, host TSC } than abusing KVM_GET_CLOCK when we don't even *care* about the KVM clock. We need a way to migrate the arch counters on platforms other than x86 too. But I'm trying to leave that part for later. At least on x86 we *do* have a way to migrate the TSC accurately, even if it's awful.
Signed-off-by: David Woodhouse dwmw@amazon.co.uk
Documentation/virt/kvm/devices/vcpu.rst | 115 ++++++++++++++++++------ arch/x86/include/uapi/asm/kvm.h | 6 ++ arch/x86/kvm/x86.c | 15 ++++ 3 files changed, 109 insertions(+), 27 deletions(-)
Reviewed-by: Paul Durrant paul@xen.org