On Tue, 10 Aug 2021 01:04:38 +0100,
Oliver Upton <oupton@xxxxxxxxxx> wrote:
>
> On Wed, Aug 4, 2021 at 3:03 PM Oliver Upton <oupton@xxxxxxxxxx> wrote:
> >
> > On Wed, Aug 4, 2021 at 4:05 AM Oliver Upton <oupton@xxxxxxxxxx> wrote:
> > >
> > > On Wed, Aug 4, 2021 at 1:58 AM Oliver Upton <oupton@xxxxxxxxxx> wrote:
> > > >
> > > > KVM's current means of saving/restoring system counters is plagued with
> > > > temporal issues. At least on ARM64 and x86, we migrate the guest's
> > > > system counter by-value through the respective guest system register
> > > > values (cntvct_el0, ia32_tsc). Restoring system counters by-value is
> > > > brittle as the state is not idempotent: the host system counter is still
> > > > oscillating between the attempted save and restore. Furthermore, VMMs
> > > > may wish to transparently live migrate guest VMs, meaning that they
> > > > include the elapsed time due to live migration blackout in the guest
> > > > system counter view. The VMM thread could be preempted for any number of
> > > > reasons (scheduler, L0 hypervisor under nested) between the time that
> > > > it calculates the desired guest counter value and when KVM actually sets
> > > > this counter state.
> > > >
> > > > Despite the value-based interface that we present to userspace, KVM
> > > > actually has idempotent guest controls by way of system counter offsets.
> > > > We can avoid all of the issues associated with a value-based interface
> > > > by abstracting these offset controls in new ioctls. This series
> > > > introduces new vCPU device attributes to provide userspace access to the
> > > > vCPU's system counter offset.
> > > >
> > > > Patch 1 addresses a possible race in KVM_GET_CLOCK where
> > > > use_master_clock is read outside of the pvclock_gtod_sync_lock.
> > > >
> > > > Patch 2 adopts Paolo's suggestion, augmenting the KVM_{GET,SET}_CLOCK
> > > > ioctls to provide userspace with a (host_tsc, realtime) instant. This is
> > > > essential for a VMM to perform precise migration of the guest's system
> > > > counters.
> > > >
> > > > Patches 3-4 are some preparatory changes for exposing the TSC offset to
> > > > userspace. Patch 5 provides a vCPU attribute to provide userspace access
> > > > to the TSC offset.
> > > >
> > > > Patches 6-7 implement a test for the new additions to
> > > > KVM_{GET,SET}_CLOCK.
> > > >
> > > > Patch 8 fixes some assertions in the kvm device attribute helpers.
> > > >
> > > > Patches 9-10 implement at test for the tsc offset attribute introduced in
> > > > patch 5.
>
> Paolo,
>
> Is there anything else you're waiting to see for the x86 portion of
> this series after addressing Sean's comments? There's some work
> remaining on the arm64 side, though I believe the two architectures
> are now disjoint for this series.
I think at this stage it would make sense to split the series in two
and drive them independently.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
