Re: Xen(arm64) hang on suspend/resume

[Julien Grall <julien@xxxxxxx>]

On 25/09/2023 12:15, Jonas Blixt wrote:
> Hello,
Hi,

> I've encountered a strange behavior with Xen on arm64 with regards to 
> suspend/resume.
>
> My setup:
> Version: Xen 4.13.1
This has been relaesed in 2019 and not even the latest point release for 
4.13 (it is 4.13.5). For new development, I would strongly recommend to 
use the latest stable (4.17) if not staging.
But you should at least use the lastest point release (4.13.5). Note 
that this tree is not anymore supported at all by the community. So it 
may contain (security) bugs.
> Target: NXP imx8x SoC
>
> We also use a set of patches from Aggios 
> (https://xen-devel.narkive.com/yGps0HKG/rfc-v2-xen-arm-suspend-to-ram-support-in-xen-for-arm)
There was a new version of the series sent in 2022 [1]. This is based on 
a more recent Xen (4.16). I would suggest to give a try and check if it 
helps.
Note that this series is still in development and has not yet been 
accepted by the community. So if there are any bugs, then I would 
recommend to contact the original author.

> Occasionally xen gets stuck on resume. We know that the lower levels wake up 
> and xen starts to resume because xen's debug console is available. When we're 
> in this state dom0 does not resume and both pCPU's are in idle loops. If we at 
> this point issue debug console commands (like 'h' for the help menu) that 
> schedule tasklets dom0 wakes up and continues. Debug function that run in the 
> irq-handler does not have the same effect.
It sounds like the dom0 vCPUs were not unblocked. That said, it is 
unclear why 'h' would help. Would you be able to print the field 
'pause_flags' for each vCPU?
You could use the key 'q' to dump all the domain information. Hopefully, 
this doesn't have a side-effect. If it has, then I would suggest to add 
some printk at boot.
Cheers,

[1] https://lore.kernel.org/cover.1665128335.git.mykyta_poturai@xxxxxxxx

--
Julien Grall