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@xxxxxxxxxxxx> > > > > 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@xxxxxxxxx/ 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@xxxxxxxxxxxx> > > --- > > 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@xxxxxxx> >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
