Re: [Xen-devel] [PATCH v2] xen: arm64: Add support for Renesas RCar Gen3 H3 Salvator-X platform

[Dirk Behme <dirk.behme@xxxxxxxxxxxx>]

Hi,

On 11.07.2016 11:25, Andre Przywara wrote:
> Hi Dirk,
>
> On 08/07/16 12:38, Dirk Behme wrote:
> > Hi Andre,
> >
> > On 05.07.2016 16:29, Andre Przywara wrote:
> > > Hi,
> > >
> > > On 05/07/16 15:22, Dirk Behme wrote:
> > > > On 05.07.2016 15:45, Andre Przywara wrote:
> > > > > Hi,
> > > > >
> > > > > On 05/07/16 14:34, Julien Grall wrote:
> > > > > > (CC Andre)
> > > > > >
> > > > > > On 05/07/16 14:04, Dirk Behme wrote:
> > > > > > > On 05.07.2016 14:45, Julien Grall wrote:
> > > > > > > > On 05/07/16 13:09, Dirk Behme wrote:
> > > > > > > > > Hi Julien,
> > > > > > > > >
> > > > > > > > > On 05.07.2016 13:39, Julien Grall wrote:
> > > > > > > > > > Hi Dirk,
> > > > > > > > > >
> > > > > > > > > > On 05/07/16 07:37, Dirk Behme wrote:
> > > > > > > > > > > Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
> > > > > > > > > > This patch looks good to me, however I would like to see the
> > > > > > > > > > documentation on the wiki page (see [1]) before giving any formal
> > > > > > > > > > ack.
> > > > > > > > >
> > > > > > > > > Ok, many thanks for your review!
> > > > > > > > >
> > > > > > > > > Yes, I understood that something more is needed.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I just wonder if we keep the patch on the mailing list for a
> > > > > > > > > moment.
> > > > > > > > > With this it's publically available and we can see how's the public
> > > > > > > > > interest for this board.
> > > > > > > > >
> > > > > > > > > Additionally, getting Xen running on this board and describe all
> > > > > > > > > this in
> > > > > > > > > the wiki isn't that easy. You either need to modify the flashed
> > > > > > > > > firmware. Or, like me, load everything via a JTAG debugger ...
> > > > > > > > Can you details why you think it is not easy? Why do you have to
> > > > > > > > modify
> > > > > > > > the firmware? Is it because it does not boot the hypervisor in EL2?
> > > > > > >
> > > > > > > The board boots via ATF, which starts U-Boot in EL1, then. You
> > > > > > > have to
> > > > > > > find a way to load Xen into memory (e.g. U-Boot TFTP) and then
> > > > > > > switch to
> > > > > > > EL2 to start Xen.
> > > > > > But ATF is running in EL3, right? If so, can ATF just starts U-boot
> > > > > > in EL2?
> > > > > >
> > > > > > I have a board at home (pine64) which also uses ATF and U-Boot and is
> > > > > > able to boot Xen without any SMC call because the U-Boot is entered
> > > > > > in EL2.
> > > > >  From having a very quick look into the rcar ATF port on github[1] I
> > > > > see:
> > > > >
> > > > > +#elif (RCAR_BL33_EXECUTION_EL == BL33_EL2)
> > > > > +    return (uint32_t)SPSR_64(MODE_EL2, MODE_SP_ELX,
> > > > > DISABLE_ALL_EXCEPTIONS);
> > > > >
> > > > > So if you rebuild ATF with RCAR_BL33_EXECUTION_EL set to BL33_EL2 that
> > > > > should enter U-Boot in EL2.
> > > > >
> > > > > The fix for the Pine64 was equally simple and works fine since then.
> > > >
> > > > This is an other solution most probably I meant when talking about
> > > > "modifying the firmware" ;)
> > > >
> > > > I'm somehow unsure about the pros and cons running U-Boot at EL1 versus
> > > > EL2, though.
> > > It shouldn't matter, really. U-Boot on AArch64 (called armv8 here) is
> > > able to run in any exception level (in contrast to ARMv7).
> > > Actually running in EL2 is the architecturally recommended way, even
> > > with ATF (by default it drops into EL2 when returning to non-secure
> > > world). On Juno (and the Pine64) is works fine this way.
> > >
> > > As U-Boot only uses an identity mapping, many differences between EL2
> > > and EL1 don't matter.
> > An understanding question regarding this: We found that running U-Boot
> > at EL2 works fine and starting Xen works fine, then, too. So many thanks
> > for that hint!
> >
> > But we found that the Linux native boot case (without Xen) does fail,
> > then. I.e. running U-Boot in EL1 starts the native Linux kernel
> > successfully. While running U-Boot in EL2 starting the native Linux
> > kernel fails, then.
> That's rather odd, can you provide some debug information?
>
> > Any idea regarding this?
> >
> > Who is responsible to switch to EL1 for the native Linux boot case if
> > U-Boot runs at EL2?
> That's well supported kernel code in arch/arm64/kernel/head.S. If it
> sees the kernel to be entered in EL2 (which is highly recommended, btw),
> it installs the KVM HYP stub and drops into EL1 (after some register setup).
> You might want to check the code in there to see if something springs to
> mind or use some debug UART output to see where it gets stuck (if it
> gets stuck). I usually do something like "mov x1, #UART_TR; mov w0,
> #'1'; str w0, [x1]" to get an idea where low level code hangs.

Just for the logs, it seems that the kernel I was using missed

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/boot/dts/renesas?id=4c811edf65e809e6ac6ec35f4818efba2b1c6163

resulting in EL2 interrupt misbehavior.


Thanks!

Best regards

Dirk

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel