Re: [patch 2/3] pvclock: detect watchdog reset at pvclock read

Don Zickus
2013-10-16T18:22:09Z

On Wed, Oct 09, 2013 at 06:26:33PM -0300, Marcelo Tosatti wrote:
> From https://lkml.org/lkml/2013/7/3/675:
>
> "Agree. However, can't see how there is a way around "having custom
> kvm/paravirt splat all over", for watchdogs that do:
>
> 1. check for watchdog resets
> 2. read time via sched_clock or xtime.
> 3. based on 2, decide whether there has been a longer delay than
> acceptable.
>
> This is the case for the softlockup timer interrupt. So the splat there
> is necessary (otherwise any potential notification of vm-pause event
> noticed at 2 might be missed because its checked at 1).
>
> For watchdogs that measure time based on interrupt event (such as hung
> task, rcu_cpu_stall, checking for the notification at sched_clock or
> lower is fine)."
>

Sorry for the delay, I was trying to spend time understanding the problem
again. Rik van Riel helped me (as I could just walk over to him).

I was trying to figure out if there was a way to convert the softlockup to
something more virt-friendly mechanism. I was toying with the idea of
having the softlockup use schedule_timeout and then have the
touch_softlockup routine keep rescheduling (delay) the timeout. The idea
was that if it actually timed out, it was guaranteed to be a lockup. This
removed the need for the duration calculation but more importantly, I
believe the schedule_timeout routine was guest time aware.

But I haven't had the chance to think through the whole thing to know if
that was the right way to go or if there was pitfalls. Just busy with
other stuff.

Regardless, I think this patchset solves a particular problem and I am ok
with it (even v2 I believe).

Cheers,
Don