On Wed, 6 Sep 2023, Stefano Stabellini wrote: > On Wed, 6 Sep 2023, Anthony Chan wrote: > > Thanks, I've tried patches that stemmed from that discussion but > > unfortunately, doesn't resolve the issue. In fact, the s2idle_loop > > branch might not be the problem at all. I experimented with Xen to allow > > the > > 'idle-states' into the FDT and prevented xen_guest_init on Linux from > > disabling > > the 'cpuidle' driver (arch/arm/xen/enlighten.c). When I trigger a suspend, > > I > > can see now another thread (believe it's the idle thread) call into > > drivers/firmware/psci/psci.c:__psci_cpu_suspend and then the Xen > > counterpart at xen/arch/arm/vpsci.c:do_psci_0_2_cpu_suspend. > > OK but remember that Xen is not implementing do_psci_0_2_cpu_suspend > correctly at the moment. Either we need to fix the Xen implementation, or we > need to configure Linux so that it calls WFI instead of __psci_cpu_suspend. > > As a test, can you try to apply the attached patch to Xen as a tenative fix? > Or > you could change drivers/firmware/psci/psci.c:__psci_cpu_suspend to call > WFI instead of the PSCI operation (making sure to go to the entry_point > instead of returning).
Tried the patch and substituting a WFI for a PSCI op, but Xen still watchdogs on the VMs in both cases. I noticed the other Linux generic arm 'cpu-idle' driver which used to do issue a WFI/cpu_do_idle isn't useable anymore either. I'm not sure if Xen may have used to rely on this generic driver to get the WFI. CONFIDENTIALITY NOTICE: This e-mail, including any attachments, may contain information that is confidential and privileged. Any unauthorized disclosure, reproduction or use of this e-mail is prohibited. If you are not the intended recipient, please notify the sender by reply e-mail or telephone and permanently delete this e-mail and any reproductions immediately.
