Re: [PATCH] xen/timer: don't migrate timers away from cpus during suspend

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.09.2022 14:41, Juergen Gross wrote:
> During a suspend/resume cycle timers on all cpus but cpu 0 will be
> migrated to cpu 0, as the other cpus are taken down.
> 
> This is problematic in case such a timer is related to a specific vcpu,
> as the vcpus are not migrated to another cpu during suspend (migrating
> them would break cpupools and core scheduling).
> 
> In order to avoid the problems just try to keep the timers on their
> cpus. Only migrate them away in case resume failed. Doing so isn't
> problematic, as any vcpu on a cpu not coming back to life would be
> migrated away, too.

The description fails to make clear what the problem is with a timer
which "is related to a specific vcpu". In principle there's no issue
with such a timer running on an arbitrary CPU. An example of a case
where a problem exists may help. This might then also clarify whether
it wouldn't be better to remove such assumptions from the (few?)
cases where they are made. Plus this might then also clarify why
this appears to be a credit1-specific issue.

Also to me "just try to keep" reads like "best effort", which isn't
what the patch does. I'd like to suggest to drop "just try to" and
maybe further insert "CPU" before "resume".

As to this not being a problem - if there are assumptions on the CPU
a timer runs on, why would this not be the case after resume? Timers
are migrated to random CPUs, and hence it's not very likely that the
vCPU would end up on the same CPU the timer was migrated to. IOW to
me it looks as if this would work only if _all_ APs failed to come
back up, and the system would continue with just the BSP.

Jan