Re: [PATCH v1 0/5] target/arm/kvm: Provide an option to adjust virtual time

[Guoheyi]

在 2019/12/11 17:00, Andrew Jones 写道:
> On Wed, Dec 11, 2019 at 04:02:52PM +0800, Guoheyi wrote:
> > 在 2019/12/6 23:22, Peter Maydell 写道:
> > > On Wed, 16 Oct 2019 at 15:34, Andrew Jones <address@hidden> wrote:
> > > > v2:
> > > >    - move from RFC status to v1
> > > >    - put kvm_arm_vm_state_change() in kvm.c to share among kvm32.c and kvm64.c
> > > >    - add r-b's from Richard
> > > >
> > > >
> > > > This series is inspired by a series[1] posted by Bijan Mottahedeh about
> > > > a year ago.  The problem described in the cover letter of [1] is easily
> > > > reproducible and some users would like to have the option to avoid it.
> > > > However the solution, which is to adjust the virtual counter offset each
> > > > time the VM transitions to the running state, introduces a different
> > > > problem, which is that the virtual and physical counters diverge.  As
> > > > described in the cover letter of [1] this divergence is easily observed
> > > > when comparing the output of `date` and `hwclock` after suspending the
> > > > guest, waiting a while, and then resuming it.  Because this different
> > > > problem may actually be worse for some users, unlike [1], the series
> > > > posted here makes the virtual counter offset adjustment optional and not
> > > > even enabled by default.  Besides the adjustment being optional, this
> > > > series approaches the needed changes differently to apply them in more
> > > > appropriate locations.  Finally, unlike [1], this series doesn't attempt
> > > > to measure "pause time" itself.  Simply using QEMU_CLOCK_VIRTUAL, which
> > > > only ticks when the VM is not stopped, is sufficient.
> > > So I guess my overall question is "what is the x86 solution to
> > > this problem, and why is this all arm-specific?" It would also
> > > be helpful to know how it fits into all the other proposals regarding
> > > time in VMs.
> > I also sent a RFC in March and ARM KVM experts were also invoved in the
> > discussion:
> >
> > https://lists.cs.columbia.edu/pipermail/kvmarm/2019-March/035026.html
> >
> > According to the discussion, qemu on x86 is using KVM_KVMCLOCK_CTRL to
> > request KVM to set a flag "PVCLOCK_GUEST_STOPPED" in pvclock, informing VM
> > kernel about external force stop.
> >
> > Thanks,
> >
> > Heyi
> Hi Heyi,
>
> Apologies for having forgotten about that thread. I recall now having
> followed it last March. Indeed it even addresses the issue in the way
> we're coming around to now (save/restore vs. update with virtual time).

Never mind :) We were also blocked by this issue when trying to support 
VM suspend/resume, save/restore, etc, so I'm happy to see your patches 
that we have the chance to fix it.

> I just reread the whole thread, and my feeling is that, while there are
> still many issues left to work, until we get a pvclock for arm, a patch
> like this one, but with a way to opt-in/out in order to give users a
> chance to choose their poison, is the best we can do. Also a patch like
> this one is a step in the right direction, as it will be needed as part
> of the bigger pvclock solution eventually, just as it is for x86.

Yes, it is simple and it works with current version of ARM64 OS 
distributions.

Thanks,

Heyi

> One comment on the patch is that I would prefer to do the save/restore
> for all VCPUs, even though KVM does currently handle synchronization.
> Not only does it "feel" more correct to apply VCPU APIs to all VCPUs,
> but I assume it will be less problematic to implement CPU hotplug at
> some point.
>
> Thanks,
> drew
>
>
> .