Hi,
On 3/28/19 1:56 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 15:33, Julien Grall <julien.gr...@arm.com> wrote:
On 3/28/19 1:01 PM, Volodymyr Babchuk wrote:
On Thu, 28 Mar 2019 at 14:09, Juergen Gross <jgr...@suse.com> 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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
