This will bounce to the mailing lists because I am on a text/plain-impaired
phone, but anyway.

One reason to have selftests is to allow having APIs that are not used by
QEMU. Still, I think Maxim had an implementation of his own TSC migration
API and it shouldn't be too hard to use the algorithm that is documented in
this series.

Paolo

Il gio 26 ago 2021, 22:28 Oliver Upton <oupton@google.com> ha scritto:

> Marcelo,
>
> On Thu, Aug 26, 2021 at 09:48:36AM -0300, Marcelo Tosatti wrote:
> > On Mon, Aug 23, 2021 at 01:56:30PM -0700, Oliver Upton wrote:
> > > Paolo,
> > >
> > > On Sun, Aug 15, 2021 at 5:11 PM Oliver Upton <oupton@google.com>
> wrote:
> > > >
> > > > To date, VMM-directed TSC synchronization and migration has been a
> bit
> > > > messy. KVM has some baked-in heuristics around TSC writes to infer if
> > > > the VMM is attempting to synchronize. This is problematic, as it
> depends
> > > > on host userspace writing to the guest's TSC within 1 second of the
> last
> > > > write.
> > > >
> > > > A much cleaner approach to configuring the guest's views of the TSC
> is to
> > > > simply migrate the TSC offset for every vCPU. Offsets are idempotent,
> > > > and thus not subject to change depending on when the VMM actually
> > > > reads/writes values from/to KVM. The VMM can then read the TSC once
> with
> > > > KVM_GET_CLOCK to capture a (realtime, host_tsc) pair at the instant
> when
> > > > the guest is paused.
> > > >
> > > > Cc: David Matlack <dmatlack@google.com>
> > > > Cc: Sean Christopherson <seanjc@google.com>
> > > > Signed-off-by: Oliver Upton <oupton@google.com>
> > >
> > > Could you please squash the following into this patch? We need to
> > > advertise KVM_CAP_VCPU_ATTRIBUTES to userspace. Otherwise, happy to
> > > resend.
> > >
> > > Thanks,
> > > Oliver
> >
> > Oliver,
> >
> > Is there QEMU support for this, or are you using your own
> > userspace with this?
>
> Apologies for not getting back to you on your first mail. Sadly, I am
> using our own userspace for this. That being said, adding support to
> QEMU shouldn't be too challenging. I can take a stab at it if it makes
> the series more amenable to upstream, with the giant disclaimer that I
> haven't done work in QEMU before. Otherwise, happy to review someone
> else's implementation.
>
> --
> Thanks,
> Oliver
>
>