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

Re: [Xen-devel] Problems building and running Xen on Hikey960

On 11/11/18 1:15 AM, Matthew Daley wrote:
Hi Julien,

Hi Matthew,

On Sat, 10 Nov 2018 at 00:22, Julien Grall <julien.grall@xxxxxxx> wrote:
Firstly, Xen fails to bring up any other CPUs but the one it is booting on:

(XEN) Bringing up CPU1
(XEN) Failed to bring up CPU1
(XEN) Failed to bring up CPU 1 (error -9)
(XEN) Bringing up CPU2
(XEN) Failed to bring up CPU2
(XEN) Failed to bring up CPU 2 (error -9)
(XEN) Bringing up CPU3
(XEN) Failed to bring up CPU3
(XEN) Failed to bring up CPU 3 (error -9)
(XEN) Bringing up CPU4
(XEN) Failed to bring up CPU4
(XEN) Failed to bring up CPU 4 (error -9)
(XEN) Bringing up CPU5
(XEN) Failed to bring up CPU5
(XEN) Failed to bring up CPU 5 (error -9)
(XEN) Bringing up CPU6
(XEN) Failed to bring up CPU6
(XEN) Failed to bring up CPU 6 (error -9)
(XEN) Bringing up CPU7
(XEN) Failed to bring up CPU7
(XEN) Failed to bring up CPU 7 (error -9)
(XEN) Brought up 1 CPUs

I have traced this error code -9 being returned by call_psci_cpu_on.

A similar error was reported a couple of months on the mailing list. From the
report, a regression was introduced between Xen 4.8 and unstable.

Unfortunately, I don't have an hikey board to bisect it. May I ask if you can
bisect it? If you can point the offending commit, I should be able to provide
ideas why it breaks.

I managed to bisect this to commit
9f954a5e90414d10632e6c2fef5a33ea8a4a1e4e. Reverting this revert (!) on
top of current master leads to the CPUs (at least the big cores, as
expected) being brought online correctly:
Thank you for bisecting Xen, it is actually poin to the commit I suspected. I have been told that entry point for secondary CPUs on the Hikey board may require to be below 4GB.

I am not entirely sure how to address this yet. Would you mind to have a try at the following patch?

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 80f00286d3..f1fdfa4c91 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -409,13 +409,11 @@ static paddr_t __init get_xen_paddr(void)
             if ( !e )

-#ifdef CONFIG_ARM_32
             /* Xen must be under 4GB */
             if ( e > 0x100000000ULL )
                 e = 0x100000000ULL;
             if ( e < bank->start )

             s = e - min_size;


...turns out that these nodes appear to belong to the little cores
(which were not brought online previously and still aren't with the
reverted revert), so munging the DT so as to remove these nodes fixes
this problem too.

We disable support of big.LITTLE by default because Xen currently assumes all the CPUs are the same. This is not the case in the big.LITTLE case.

You can override that behavior by adding hmp-unsafe on Xen command line.


Julien Grall

Xen-devel mailing list



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