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

[Julien Grall <julien.grall@xxxxxxx>]

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 )
                 continue;

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

             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.

Cheers,

--
Julien Grall

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