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

[Guoheyi <guoheyi@huawei.com>]

在 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 <drjones@redhat.com> 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
>
>
> .