[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/6] xen: simplify suspend/resume handling



Hi,

On 3/28/19 1:56 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 15:33, Julien Grall <julien.grall@xxxxxxx> wrote:
On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 14:09, Juergen Gross <jgross@xxxxxxxx> wrote:

(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) PSCI cpu off failed for CPU0 err=-3
(XEN) ****************************************

PSCI CPU off failing is never a good news. Here, the command has been
denied by PSCI monitor. But... why does CPU off is actually called on
CPU0? Shouldn't we have turned off the platform instead?
I think, this is because CPU1 is performing machine_restart(), so it
asked CPU0 to halt itself.

The PSCI call SYSTEM_OFF/SYSTEM_RESET requires all the CPUs to be in a known state. The PSCI spec actually suggest to turn all the CPUs but one off. Another alternative is to put them in a quiescent state.

CPU_OFF will return -3 (i.e DENIED) if the Trusted OS is Uniprocessor and resides on the core that you are about to turn off. I assume your platform have a TOS UP and currently resides on CPU0.

SYSTEM_OFF/SYSTEM_RESET call can be done from any CPUs. If we want to avoid the problem with CPU_OFF, then the best options is to put the all CPUs but one in a quiescent state (something like while (1) cpu_relax/wfi).

On a side node, we should probably want to remove the panic in call_psci_cpu_off as this will be used by the suspend code. Indeed, the trusted OS may not reside on the boot CPU, so you may hit the panic as well.



(XEN)
(XEN) Reboot in five seconds...

Are the logs below actually a mistaken paste?
No, this is what I'm seeing in my serial console.

I guess this is happening because we recurse in machine_halt(). We probably want to drop any panic in that code path.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.