[boot-wrapper 7/7] aarch64: Start Xen on Armv8-R at EL2

[Andre Przywara]

On Mon, 24 Jun 2024 14:28:24 +0100
Luca Fancellu <Luca.Fancellu at arm.com> wrote:

> Hi Andre,
> 
> > On 21 Jun 2024, at 11:36, Andre Przywara <Andre.Przywara at arm.com> wrote:
> >
> > On Thu,  6 Jun 2024 14:36:28 +0100
> > Luca Fancellu <luca.fancellu at arm.com> wrote:
> >
> > Hi,
> >  
> >> When bootwrapper is compiled with Xen support and it is started
> >> at EL2 on Armv8-R AArch64, keep the current EL and jump to the
> >> Xen image.
> >>
> >> Additionally, don't permit the usage of hvc conduit when Xen
> >> kernel is passed, because it's not supported.  
> >
> > Mmh, but this is unrelated to v8R, isn't it?
> > And I am not sure there is too much merit in checking this here?
> > After all PSCI *could* be triggered like this from EL2 (to EL2) in the
> > future, even if the *current* Xen implementation does not support this.  
> 
> Yes, it’s only the current Xen implementation that doesn’t support this.
> 
> >  
> >> Signed-off-by: Luca Fancellu <luca.fancellu at arm.com>
> >> ---
> >> Makefile.am         | 1 +
> >> arch/aarch64/boot.S | 7 +++++++
> >> configure.ac        | 3 +++
> >> 3 files changed, 11 insertions(+)
> >>
> >> diff --git a/Makefile.am b/Makefile.am
> >> index 34fbfb1f4ff8..bafce34682c3 100644
> >> --- a/Makefile.am
> >> +++ b/Makefile.am
> >> @@ -112,6 +112,7 @@ XEN_CHOSEN := xen,xen-bootargs = \"$(XEN_CMDLINE)\"; \
> >> compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> >> reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>; \
> >>   };
> >> +DEFINES += -DXEN
> >> endif
> >>
> >> if INITRD
> >> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S
> >> index b2b9863b8d6a..0b30b82ad6d9 100644
> >> --- a/arch/aarch64/boot.S
> >> +++ b/arch/aarch64/boot.S
> >> @@ -88,6 +88,7 @@ reset_at_el2:
> >> cmp x0, 0xf
> >> bne reset_no_el3
> >>
> >> +#if !defined(XEN)
> >> /*
> >> * Armv8-R AArch64 is found, check if Linux can be booted.  
> >
> > Does Xen equally rely on VMSA in EL1? Or does it not care, and just
> > leaves the EL1 setup totally to the guest? Supporting PMSA guests
> > as well?
> > Just asking to check whether the !XEN part would be in the right place
> > then.  
> 
> Xen does not care and it just leaves the EL1 setup to the guest.
> 
> >  
> >> * Check MSA_frac, bits [55:52]:
> >> @@ -107,6 +108,12 @@ reset_at_el2:
> >> mov w0, #SPSR_KERNEL_EL1
> >> ldr x1, =spsr_to_elx
> >> str w0, [x1]
> >> +#else
> >> + /* Start XEN on Armv8-R at EL2 */
> >> + mov w0, #1
> >> + ldr x1, =flag_keep_el
> >> + str w0, [x1]
> >> +#endif
> >>
> >> cpuid x0, x1
> >> bl find_logical_id
> >> diff --git a/configure.ac b/configure.ac
> >> index 44459a4c849e..a5175db4148a 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -95,6 +95,9 @@ AM_CONDITIONAL([PSCI_HVC], [test "x$USE_PSCI" = "xhvc"])
> >> AS_IF([test "x$USE_PSCI" = "xno" -a "x$KERNEL_ES" = "x32"],
> >> [AC_MSG_ERROR([With an AArch32 kernel, boot method must be PSCI.])]
> >> )
> >> +AS_IF([test "x$USE_PSCI" = "xhvc" -a "x$X_IMAGE" != "x"],
> >> + [AC_MSG_ERROR([With Xen kernel, PSCI conduit must be smc.])]
> >> +)  
> >
> > As mentioned above, I am not sure this is too helpful.  
> 
> Ok, so your proposal is to remove this check, am I right?

Yes, I think this is overzealous.

Cheers,
Andre