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

[Matthew Daley <mattd@xxxxxxxxxxx>]

On Tue, 13 Nov 2018 at 02:01, Julien Grall <julien.grall@xxxxxxx> wrote:
> 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;
>

I gave this a go but unfortunately the same problem occurs (error
-9s). Just to check nothing weird is happening I added a printk to
check the value of __pa(init_secondary) in call_psci_cpu_on, giving
0xdfe00180.

> > ...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.

Right.

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