Re: [PATCH v3] xen/vcpu: ignore VCPU_SSHOTTMR_future

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, May 03, 2023 at 12:38:59PM +0200, Jan Beulich wrote:
> On 19.04.2023 16:31, Roger Pau Monne wrote:
> > The usage of VCPU_SSHOTTMR_future in Linux prior to 4.7 is bogus.
> > When the hypervisor returns -ETIME (timeout in the past) Linux keeps
> > retrying to setup the timer with a higher timeout instead of
> > self-injecting a timer interrupt.
> > 
> > On boxes without any hardware assistance for logdirty we have seen HVM
> > Linux guests < 4.7 with 32vCPUs give up trying to setup the timer when
> > logdirty is enabled:
> > 
> > CE: Reprogramming failure. Giving up
> > CE: xen increased min_delta_ns to 1000000 nsec
> > CE: Reprogramming failure. Giving up
> > CE: Reprogramming failure. Giving up
> > CE: xen increased min_delta_ns to 506250 nsec
> > CE: xen increased min_delta_ns to 759375 nsec
> > CE: xen increased min_delta_ns to 1000000 nsec
> > CE: Reprogramming failure. Giving up
> > CE: Reprogramming failure. Giving up
> > CE: Reprogramming failure. Giving up
> > Freezing user space processes ...
> > INFO: rcu_sched detected stalls on CPUs/tasks: { 14} (detected by 10, 
> > t=60002 jiffies, g=4006, c=4005, q=14130)
> > Task dump for CPU 14:
> > swapper/14      R  running task        0     0      1 0x00000000
> > Call Trace:
> >  [<ffffffff90160f5d>] ? rcu_eqs_enter_common.isra.30+0x3d/0xf0
> >  [<ffffffff907b9bde>] ? default_idle+0x1e/0xd0
> >  [<ffffffff90039570>] ? arch_cpu_idle+0x20/0xc0
> >  [<ffffffff9010820a>] ? cpu_startup_entry+0x14a/0x1e0
> >  [<ffffffff9005d3a7>] ? start_secondary+0x1f7/0x270
> >  [<ffffffff900000d5>] ? start_cpu+0x5/0x14
> > INFO: rcu_sched detected stalls on CPUs/tasks: { 26} (detected by 24, 
> > t=60002 jiffies, g=6922, c=6921, q=7013)
> > Task dump for CPU 26:
> > swapper/26      R  running task        0     0      1 0x00000000
> > Call Trace:
> >  [<ffffffff90160f5d>] ? rcu_eqs_enter_common.isra.30+0x3d/0xf0
> >  [<ffffffff907b9bde>] ? default_idle+0x1e/0xd0
> >  [<ffffffff90039570>] ? arch_cpu_idle+0x20/0xc0
> >  [<ffffffff9010820a>] ? cpu_startup_entry+0x14a/0x1e0
> >  [<ffffffff9005d3a7>] ? start_secondary+0x1f7/0x270
> >  [<ffffffff900000d5>] ? start_cpu+0x5/0x14
> > INFO: rcu_sched detected stalls on CPUs/tasks: { 26} (detected by 24, 
> > t=60002 jiffies, g=8499, c=8498, q=7664)
> > Task dump for CPU 26:
> > swapper/26      R  running task        0     0      1 0x00000000
> > Call Trace:
> >  [<ffffffff90160f5d>] ? rcu_eqs_enter_common.isra.30+0x3d/0xf0
> >  [<ffffffff907b9bde>] ? default_idle+0x1e/0xd0
> >  [<ffffffff90039570>] ? arch_cpu_idle+0x20/0xc0
> >  [<ffffffff9010820a>] ? cpu_startup_entry+0x14a/0x1e0
> >  [<ffffffff9005d3a7>] ? start_secondary+0x1f7/0x270
> >  [<ffffffff900000d5>] ? start_cpu+0x5/0x14
> > 
> > Thus leading to CPU stalls and a broken system as a result.
> > 
> > Workaround this bogus usage by ignoring the VCPU_SSHOTTMR_future in
> > the hypervisor.  Old Linux versions are the only ones known to have
> > (wrongly) attempted to use the flag, and ignoring it is compatible
> > with the behavior expected by any guests setting that flag.
> > 
> > Note the usage of the flag has been removed from Linux by commit:
> > 
> > c06b6d70feb3 xen/x86: don't lose event interrupts
> > 
> > Which landed in Linux 4.7.
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> > Acked-by: Henry Wang <Henry.Wang@xxxxxxx> # CHANGELOG
> 
> A little hesitantly, but since no-one else appears to show any interest:
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

Roger.