diff mbox series

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

Message ID 20240606133628.3330423-8-luca.fancellu@arm.com (mailing list archive)
State New, archived
Headers show
Series Add Armv8-R AArch64 support | expand

Commit Message

Luca Fancellu June 6, 2024, 1:36 p.m. UTC
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.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
 Makefile.am         | 1 +
 arch/aarch64/boot.S | 7 +++++++
 configure.ac        | 3 +++
 3 files changed, 11 insertions(+)

Comments

Andre Przywara June 21, 2024, 10:36 a.m. UTC | #1
On Thu,  6 Jun 2024 14:36:28 +0100
Luca Fancellu <luca.fancellu@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.

> Signed-off-by: Luca Fancellu <luca.fancellu@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.

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

Cheers,
Andre

>  AC_SUBST([PSCI_METHOD], [$USE_PSCI])
>  
>  # Allow a user to pass --with-initrd
Luca Fancellu June 24, 2024, 1:28 p.m. UTC | #2
Hi Andre,

> On 21 Jun 2024, at 11:36, Andre Przywara <Andre.Przywara@arm.com> wrote:
> 
> On Thu,  6 Jun 2024 14:36:28 +0100
> Luca Fancellu <luca.fancellu@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@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?

Cheers,
Luca
Luca Fancellu July 15, 2024, 7:16 a.m. UTC | #3
Hi Andre,

> 
>> 
>>> * 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?

Gentle ping on this.

Cheers,
Luca
Andre Przywara July 15, 2024, 1:12 p.m. UTC | #4
On Mon, 24 Jun 2024 14:28:24 +0100
Luca Fancellu <Luca.Fancellu@arm.com> wrote:

> Hi Andre,
> 
> > On 21 Jun 2024, at 11:36, Andre Przywara <Andre.Przywara@arm.com> wrote:
> >
> > On Thu,  6 Jun 2024 14:36:28 +0100
> > Luca Fancellu <luca.fancellu@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@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
diff mbox series

Patch

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.
 	 * 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.])]
+)
 AC_SUBST([PSCI_METHOD], [$USE_PSCI])
 
 # Allow a user to pass --with-initrd