Re: [Qemu-arm] [RFC] arm/cpu: fix soft lockup panic after resuming from stop

[Heyi Guo]

Hi Christoffer and Steve,


On 2019/3/15 16:59, Christoffer Dall wrote:
> Hi Steve,
>
> On Wed, Mar 13, 2019 at 10:11:30AM +0000, Steven Price wrote:
> > Personally I think what we need is:
> >
> > * Either a patch like the one from Heyi Guo (save/restore CNTVCT_EL0) or
> > alternatively hooking up KVM_KVMCLOCK_CTRL to prevent the watchdog
> > firing when user space explicitly stops scheduling the guest for a while.
> If we save/restore CNTVCT_EL0 and the warning goes away, does the guest
> wall clock timekeeping get all confused and does it figure this out
> automagically somehow?
What's the source for guest wall clock timekeeping in current ARM64 
implementation? Is it the value from CNTP_TVAL_EL0? Will guest OS keep track of 
this? Or is the wall clock simply platform RTC?

I tested the RFC change and did not see anything unusual. Did I miss someting?

> Does KVM_KVMCLOCK_CTRL solve that problem?
It seems KVM_KVMCLOCK_CTRL is dedicated for guest pause/resume scenario, but it 
relies on pvclock both in KVM and Guest and right now only X86 supports it :(

Could Steve provide more insights about the whole thing?

Thanks,
Heyi

> > * KVM itself saving/restoring CNTVCT_EL0 during suspend/resume so the
> > guest doesn't see time pass during a suspend.
> This smells like policy to me so I'd much prefer keeping as much
> functionality in user space as possible.  If we already have the APIs we
> need from KVM, let's use them.
>
> > * Something equivalent to MSR_KVM_WALL_CLOCK_NEW for arm which allows
> > the guest to query the wall clock time from the host and provides an
> > offset between CNTVCT_EL0 to wall clock time which the KVM can update
> > during suspend/resume. This means that during a suspend/resume the guest
> > can observe that wall clock time has passed, without having to be
> > bothered about CNTVCT_EL0 jumping forwards.
> Isn't the proper Arm architectural solution for this to read the
> physical counter for wall clock time keeping ?
>
> (Yes that will require a trap on physical counter reads after migration
> on current systems, but migration sucks in terms of timekeeping
> already.)
>
>
> Thanks,
>
>      Christoffer
>
> .