xen/arch/arm/arch.mk | 1 + xen/arch/arm/arm64/vfp.c | 6 ++++++ 2 files changed, 7 insertions(+)
This patch enables building Xen on arm64 architecture using the Clang compiler.
Changes include:
- Add explicit -march=armv8 flag for arm64 builds.
- Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
`vfp_restore_state` functions when building with Clang to allow
FP instructions despite `-mgeneral-regs-only`.
Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
---
xen/arch/arm/arch.mk | 1 +
xen/arch/arm/arm64/vfp.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
index 9c4bedfb3b..bcf548069b 100644
--- a/xen/arch/arm/arch.mk
+++ b/xen/arch/arm/arch.mk
@@ -13,6 +13,7 @@ ifeq ($(CONFIG_MPU),y)
CFLAGS-$(CONFIG_ARM_64) += -march=armv8-r
else
CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
+CFLAGS-$(CONFIG_ARM_64) += -march=armv8
endif
CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
$(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
diff --git a/xen/arch/arm/arm64/vfp.c b/xen/arch/arm/arm64/vfp.c
index c4f89c7b0e..51fd2ddc54 100644
--- a/xen/arch/arm/arm64/vfp.c
+++ b/xen/arch/arm/arm64/vfp.c
@@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
: : "Q" (*fpregs), "r" (fpregs));
}
+#if defined(CONFIG_CC_IS_CLANG)
+__attribute__((target("fp-armv8")))
+#endif
void vfp_save_state(struct vcpu *v)
{
if ( !cpu_has_fp )
@@ -62,6 +65,9 @@ void vfp_save_state(struct vcpu *v)
v->arch.vfp.fpexc32_el2 = READ_SYSREG(FPEXC32_EL2);
}
+#if defined(CONFIG_CC_IS_CLANG)
+__attribute__((target("fp-armv8")))
+#endif
void vfp_restore_state(struct vcpu *v)
{
if ( !cpu_has_fp )
--
2.49.0On 09.12.2025 01:37, Saman Dehghan wrote:
> This patch enables building Xen on arm64 architecture using the Clang compiler.
> Changes include:
> - Add explicit -march=armv8 flag for arm64 builds.
> - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> `vfp_restore_state` functions when building with Clang to allow
> FP instructions despite `-mgeneral-regs-only`.
>
> Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> ---
> xen/arch/arm/arch.mk | 1 +
> xen/arch/arm/arm64/vfp.c | 6 ++++++
> 2 files changed, 7 insertions(+)
Please also update ./README then accordingly.
> --- a/xen/arch/arm/arm64/vfp.c
> +++ b/xen/arch/arm/arm64/vfp.c
> @@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
> : : "Q" (*fpregs), "r" (fpregs));
> }
>
> +#if defined(CONFIG_CC_IS_CLANG)
> +__attribute__((target("fp-armv8")))
> +#endif
> void vfp_save_state(struct vcpu *v)
> {
> if ( !cpu_has_fp )
> @@ -62,6 +65,9 @@ void vfp_save_state(struct vcpu *v)
> v->arch.vfp.fpexc32_el2 = READ_SYSREG(FPEXC32_EL2);
> }
>
> +#if defined(CONFIG_CC_IS_CLANG)
> +__attribute__((target("fp-armv8")))
> +#endif
> void vfp_restore_state(struct vcpu *v)
> {
> if ( !cpu_has_fp )
Aren't it save_state() and restore_state() which actually use FP registers?
Applying such attributes in too wide a fashion risks the compiler using FP
registers also for other purposes. On x86 we were hit by such when we
suppressed use of SSE registers while not suppressing use of MMX ones. In
some configuration, after many years of this having gone fine, the compiler
chose to use MMX insns for some odd reason.
Seeing that save_state() and restore_state() are a single asm() statement
each, any reason not to actually have them in an assembly file, just like
their SVE counterparts are?
Jan
On Tue, Dec 9, 2025 at 1:49 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.12.2025 01:37, Saman Dehghan wrote:
> > This patch enables building Xen on arm64 architecture using the Clang compiler.
> > Changes include:
> > - Add explicit -march=armv8 flag for arm64 builds.
> > - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> > `vfp_restore_state` functions when building with Clang to allow
> > FP instructions despite `-mgeneral-regs-only`.
> >
> > Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> > ---
> > xen/arch/arm/arch.mk | 1 +
> > xen/arch/arm/arm64/vfp.c | 6 ++++++
> > 2 files changed, 7 insertions(+)
>
> Please also update ./README then accordingly.
Thank you, Jan, I will do that.
~Saman
>
> > --- a/xen/arch/arm/arm64/vfp.c
> > +++ b/xen/arch/arm/arm64/vfp.c
> > @@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
> > : : "Q" (*fpregs), "r" (fpregs));
> > }
> >
> > +#if defined(CONFIG_CC_IS_CLANG)
> > +__attribute__((target("fp-armv8")))
> > +#endif
> > void vfp_save_state(struct vcpu *v)
> > {
> > if ( !cpu_has_fp )
> > @@ -62,6 +65,9 @@ void vfp_save_state(struct vcpu *v)
> > v->arch.vfp.fpexc32_el2 = READ_SYSREG(FPEXC32_EL2);
> > }
> >
> > +#if defined(CONFIG_CC_IS_CLANG)
> > +__attribute__((target("fp-armv8")))
> > +#endif
> > void vfp_restore_state(struct vcpu *v)
> > {
> > if ( !cpu_has_fp )
>
> Aren't it save_state() and restore_state() which actually use FP registers?
> Applying such attributes in too wide a fashion risks the compiler using FP
> registers also for other purposes. On x86 we were hit by such when we
> suppressed use of SSE registers while not suppressing use of MMX ones. In
> some configuration, after many years of this having gone fine, the compiler
> chose to use MMX insns for some odd reason.
>
> Seeing that save_state() and restore_state() are a single asm() statement
> each, any reason not to actually have them in an assembly file, just like
> their SVE counterparts are?
>
On top of those, `READ_SYSREG(FPSR)`, `READ_SYSREG(FPCR)`,
`WRITE_SYSREG(v->arch.vfp.fpsr, FPSR)`and
`WRITE_SYSREG(v->arch.vfp.fpcr, FPCR)` using FP.
I think I cannot apply __attribute__ on statements.
~Saman
> Jan
This patch enables building Xen on arm64 architecture using the Clang compiler.
Changes include:
- Add explicit -march=armv8 flag for arm64 builds.
- Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
`vfp_restore_state` functions when building with Clang to allow
FP instructions despite `-mgeneral-regs-only`.
Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
---
README | 2 ++
xen/arch/arm/arch.mk | 1 +
xen/arch/arm/arm64/vfp.c | 6 ++++++
3 files changed, 9 insertions(+)
diff --git a/README b/README
index 889a4ea906..67c1aa7fe6 100644
--- a/README
+++ b/README
@@ -45,6 +45,8 @@ provided by your OS distributor:
- For ARM:
- GCC 5.1 or later
- GNU Binutils 2.25 or later
+ or
+ - Clang/LLVM 11 or later
- For RISC-V 64-bit:
- GCC 12.2 or later
- GNU Binutils 2.39 or later
diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
index 9c4bedfb3b..bcf548069b 100644
--- a/xen/arch/arm/arch.mk
+++ b/xen/arch/arm/arch.mk
@@ -13,6 +13,7 @@ ifeq ($(CONFIG_MPU),y)
CFLAGS-$(CONFIG_ARM_64) += -march=armv8-r
else
CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
+CFLAGS-$(CONFIG_ARM_64) += -march=armv8
endif
CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
$(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
diff --git a/xen/arch/arm/arm64/vfp.c b/xen/arch/arm/arm64/vfp.c
index c4f89c7b0e..51fd2ddc54 100644
--- a/xen/arch/arm/arm64/vfp.c
+++ b/xen/arch/arm/arm64/vfp.c
@@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
: : "Q" (*fpregs), "r" (fpregs));
}
+#if defined(CONFIG_CC_IS_CLANG)
+__attribute__((target("fp-armv8")))
+#endif
void vfp_save_state(struct vcpu *v)
{
if ( !cpu_has_fp )
@@ -62,6 +65,9 @@ void vfp_save_state(struct vcpu *v)
v->arch.vfp.fpexc32_el2 = READ_SYSREG(FPEXC32_EL2);
}
+#if defined(CONFIG_CC_IS_CLANG)
+__attribute__((target("fp-armv8")))
+#endif
void vfp_restore_state(struct vcpu *v)
{
if ( !cpu_has_fp )
--
2.49.0
On 11/12/2025 02:39, Saman Dehghan wrote:
> This patch enables building Xen on arm64 architecture using the Clang compiler.
> Changes include:
> - Add explicit -march=armv8 flag for arm64 builds.
> - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> `vfp_restore_state` functions when building with Clang to allow
> FP instructions despite `-mgeneral-regs-only`.
>
> Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> ---
> README | 2 ++
> xen/arch/arm/arch.mk | 1 +
> xen/arch/arm/arm64/vfp.c | 6 ++++++
> 3 files changed, 9 insertions(+)
>
> diff --git a/README b/README
> index 889a4ea906..67c1aa7fe6 100644
> --- a/README
> +++ b/README
> @@ -45,6 +45,8 @@ provided by your OS distributor:
> - For ARM:
> - GCC 5.1 or later
> - GNU Binutils 2.25 or later
> + or
> + - Clang/LLVM 11 or later
I forgot to ask. Is this cross-compiling or native? Or both?
And OOI, how did you chose Clang 11?
Cheers,
--
Julien Grall
On Thu, Dec 11, 2025 at 3:35 AM Julien Grall <julien@xen.org> wrote:
>
>
>
> On 11/12/2025 02:39, Saman Dehghan wrote:
> > This patch enables building Xen on arm64 architecture using the Clang compiler.
> > Changes include:
> > - Add explicit -march=armv8 flag for arm64 builds.
> > - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> > `vfp_restore_state` functions when building with Clang to allow
> > FP instructions despite `-mgeneral-regs-only`.
> >
> > Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> > ---
> > README | 2 ++
> > xen/arch/arm/arch.mk | 1 +
> > xen/arch/arm/arm64/vfp.c | 6 ++++++
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/README b/README
> > index 889a4ea906..67c1aa7fe6 100644
> > --- a/README
> > +++ b/README
> > @@ -45,6 +45,8 @@ provided by your OS distributor:
> > - For ARM:
> > - GCC 5.1 or later
> > - GNU Binutils 2.25 or later
> > + or
> > + - Clang/LLVM 11 or later
>
> I forgot to ask. Is this cross-compiling or native? Or both?
>
> And OOI, how did you chose Clang 11?
Hi Julien,
To be consistent with minimum requirements for Clang/LLVM on x86.
~Saman
>
> Cheers,
>
> --
> Julien Grall
>
Hi, On 11/12/2025 12:49, Saman Dehghan wrote: >> And OOI, how did you chose Clang 11? > > Hi Julien, > > To be consistent with minimum requirements for Clang/LLVM on x86. To double check did you try the version and confirm every works? Cheers, -- Julien Grall
On Thu, Dec 11, 2025 at 9:06 AM Julien Grall <julien@xen.org> wrote:
>
> Hi,
>
> On 11/12/2025 12:49, Saman Dehghan wrote:
> >> And OOI, how did you chose Clang 11?
> >
> > Hi Julien,
> >
> > To be consistent with minimum requirements for Clang/LLVM on x86.
>
> To double check did you try the version and confirm every works?
Hi Julien,
I compiled and booted Xen with Clang-{11 - 20} on both native and
CROSS_COMPILE=aarch64-linux-gnu-.
~Saman
>
> Cheers,
>
> --
> Julien Grall
>
Hi Saman,
A bit of process first. Usually, when sending a v2, a new thread is
started (IOW, this is not sent in reply to v1).
On 11/12/2025 02:39, Saman Dehghan wrote:
> This patch enables building Xen on arm64 architecture using the Clang compiler.
> Changes include:
> - Add explicit -march=armv8 flag for arm64 builds.
> - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> `vfp_restore_state` functions when building with Clang to allow
> FP instructions despite `-mgeneral-regs-only`.
>
> Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> ---
> README | 2 ++
> xen/arch/arm/arch.mk | 1 +
> xen/arch/arm/arm64/vfp.c | 6 ++++++
> 3 files changed, 9 insertions(+)
>
> diff --git a/README b/README
> index 889a4ea906..67c1aa7fe6 100644
> --- a/README
> +++ b/README
> @@ -45,6 +45,8 @@ provided by your OS distributor:
> - For ARM:
> - GCC 5.1 or later
> - GNU Binutils 2.25 or later
> + or
> + - Clang/LLVM 11 or later
> - For RISC-V 64-bit:
> - GCC 12.2 or later
> - GNU Binutils 2.39 or later
> diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
> index 9c4bedfb3b..bcf548069b 100644
> --- a/xen/arch/arm/arch.mk
> +++ b/xen/arch/arm/arch.mk
> @@ -13,6 +13,7 @@ ifeq ($(CONFIG_MPU),y)
> CFLAGS-$(CONFIG_ARM_64) += -march=armv8-r
> else
> CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
> +CFLAGS-$(CONFIG_ARM_64) += -march=armv8
> endif
> CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
> $(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
> diff --git a/xen/arch/arm/arm64/vfp.c b/xen/arch/arm/arm64/vfp.c
> index c4f89c7b0e..51fd2ddc54 100644
> --- a/xen/arch/arm/arm64/vfp.c
> +++ b/xen/arch/arm/arm64/vfp.c
> @@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
> : : "Q" (*fpregs), "r" (fpregs));
> }
>
> +#if defined(CONFIG_CC_IS_CLANG)
> +__attribute__((target("fp-armv8")))
> +#endif
Based on Jan's comment, I am a bit puzzled why adding #ifdef is
sufficient. In fact, I do agree with Jan, my understanding of
target(...) is this will impact the ABI.
I haven't experienced any issue with the C side yet. But I know in the
Rust world (they also have an LLVM backend), they decided to prevent
enabling fp/neon [1] at the function level.
Did you find any documentation that would suggest this is safe?
Now regarding the issue you mentioned in v1:
> On top of those, `READ_SYSREG(FPSR)`, `READ_SYSREG(FPCR)`,
> `WRITE_SYSREG(v->arch.vfp.fpsr, FPSR)`and
> `WRITE_SYSREG(v->arch.vfp.fpcr, FPCR)` using FP.
> I think I cannot apply __attribute__ on statements.
Do you mean the compiler will complain that you are trying to access
FPCR/FPSR if you don't add the __atribute__ at the function level?
If so, what you could possibly do is either rewriting the functions in
assembly or open-code the "{WRITE, READ}_SYSREG()" and add a line
".arch_extension fp".
Cheers,
[1] https://github.com/llvm/llvm-project/issues/110632
--
Julien Grall
On Thu, Dec 11, 2025 at 3:33 AM Julien Grall <julien@xen.org> wrote:
>
> Hi Saman,
>
> A bit of process first. Usually, when sending a v2, a new thread is
> started (IOW, this is not sent in reply to v1).
Hi Julien,
Thanks :)
>
> On 11/12/2025 02:39, Saman Dehghan wrote:
> > This patch enables building Xen on arm64 architecture using the Clang compiler.
> > Changes include:
> > - Add explicit -march=armv8 flag for arm64 builds.
> > - Add `__attribute__((target("fp-armv8")))` to `vfp_save_state` and
> > `vfp_restore_state` functions when building with Clang to allow
> > FP instructions despite `-mgeneral-regs-only`.
> >
> > Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
> > ---
> > README | 2 ++
> > xen/arch/arm/arch.mk | 1 +
> > xen/arch/arm/arm64/vfp.c | 6 ++++++
> > 3 files changed, 9 insertions(+)
> >
> > diff --git a/README b/README
> > index 889a4ea906..67c1aa7fe6 100644
> > --- a/README
> > +++ b/README
> > @@ -45,6 +45,8 @@ provided by your OS distributor:
> > - For ARM:
> > - GCC 5.1 or later
> > - GNU Binutils 2.25 or later
> > + or
> > + - Clang/LLVM 11 or later
> > - For RISC-V 64-bit:
> > - GCC 12.2 or later
> > - GNU Binutils 2.39 or later
> > diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
> > index 9c4bedfb3b..bcf548069b 100644
> > --- a/xen/arch/arm/arch.mk
> > +++ b/xen/arch/arm/arch.mk
> > @@ -13,6 +13,7 @@ ifeq ($(CONFIG_MPU),y)
> > CFLAGS-$(CONFIG_ARM_64) += -march=armv8-r
> > else
> > CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
> > +CFLAGS-$(CONFIG_ARM_64) += -march=armv8
> > endif
> > CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
> > $(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
> > diff --git a/xen/arch/arm/arm64/vfp.c b/xen/arch/arm/arm64/vfp.c
> > index c4f89c7b0e..51fd2ddc54 100644
> > --- a/xen/arch/arm/arm64/vfp.c
> > +++ b/xen/arch/arm/arm64/vfp.c
> > @@ -46,6 +46,9 @@ static inline void restore_state(const uint64_t *fpregs)
> > : : "Q" (*fpregs), "r" (fpregs));
> > }
> >
> > +#if defined(CONFIG_CC_IS_CLANG)
> > +__attribute__((target("fp-armv8")))
> > +#endif
>
> Based on Jan's comment, I am a bit puzzled why adding #ifdef is
> sufficient. In fact, I do agree with Jan, my understanding of
> target(...) is this will impact the ABI.
>
> I haven't experienced any issue with the C side yet. But I know in the
> Rust world (they also have an LLVM backend), they decided to prevent
> enabling fp/neon [1] at the function level.
>
> Did you find any documentation that would suggest this is safe?
>
> Now regarding the issue you mentioned in v1:
>
> > On top of those, `READ_SYSREG(FPSR)`, `READ_SYSREG(FPCR)`,
> > `WRITE_SYSREG(v->arch.vfp.fpsr, FPSR)`and
> > `WRITE_SYSREG(v->arch.vfp.fpcr, FPCR)` using FP.
> > I think I cannot apply __attribute__ on statements.
>
> Do you mean the compiler will complain that you are trying to access
> FPCR/FPSR if you don't add the __atribute__ at the function level?
>
> If so, what you could possibly do is either rewriting the functions in
> assembly or open-code the "{WRITE, READ}_SYSREG()" and add a line
> ".arch_extension fp".
I couldn't find any documentation to suggest that it is safe. I will
do what you and Jan suggested and use ".arch_extension fp".
~Saman
>
> Cheers,
>
> [1] https://github.com/llvm/llvm-project/issues/110632
>
> --
> Julien Grall
>
This patch enables building Xen for the arm64 using the Clang/LLVM compiler.
Changes include:
- Add explicit -march=armv8 flag for arm64 builds.
- Introduce `READ_FP_SYSREG` and `WRITE_FP_SYSREG` to encapsulate the required
`.arch_extension fp` directive for system fp register access.
- Add ".arch_extension fp" to the inline assembly for `save_state` and
`restore_state`.
Signed-off-by: Saman Dehghan <samaan.dehghan@gmail.com>
---
README | 2 ++
xen/arch/arm/arch.mk | 1 +
xen/arch/arm/arm64/vfp.c | 30 ++++++++++++++++++++++--------
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/README b/README
index 889a4ea906..67c1aa7fe6 100644
--- a/README
+++ b/README
@@ -45,6 +45,8 @@ provided by your OS distributor:
- For ARM:
- GCC 5.1 or later
- GNU Binutils 2.25 or later
+ or
+ - Clang/LLVM 11 or later
- For RISC-V 64-bit:
- GCC 12.2 or later
- GNU Binutils 2.39 or later
diff --git a/xen/arch/arm/arch.mk b/xen/arch/arm/arch.mk
index 9c4bedfb3b..bcf548069b 100644
--- a/xen/arch/arm/arch.mk
+++ b/xen/arch/arm/arch.mk
@@ -13,6 +13,7 @@ ifeq ($(CONFIG_MPU),y)
CFLAGS-$(CONFIG_ARM_64) += -march=armv8-r
else
CFLAGS-$(CONFIG_ARM_64) += -mcpu=generic
+CFLAGS-$(CONFIG_ARM_64) += -march=armv8
endif
CFLAGS-$(CONFIG_ARM_64) += -mgeneral-regs-only # No fp registers etc
$(call cc-option-add,CFLAGS-$(CONFIG_ARM_64),CC,-mno-outline-atomics)
diff --git a/xen/arch/arm/arm64/vfp.c b/xen/arch/arm/arm64/vfp.c
index c4f89c7b0e..ea75c7a2b2 100644
--- a/xen/arch/arm/arm64/vfp.c
+++ b/xen/arch/arm/arm64/vfp.c
@@ -6,7 +6,8 @@
static inline void save_state(uint64_t *fpregs)
{
- asm volatile("stp q0, q1, [%1, #16 * 0]\n\t"
+ asm volatile(".arch_extension fp\n\t"
+ "stp q0, q1, [%1, #16 * 0]\n\t"
"stp q2, q3, [%1, #16 * 2]\n\t"
"stp q4, q5, [%1, #16 * 4]\n\t"
"stp q6, q7, [%1, #16 * 6]\n\t"
@@ -27,7 +28,8 @@ static inline void save_state(uint64_t *fpregs)
static inline void restore_state(const uint64_t *fpregs)
{
- asm volatile("ldp q0, q1, [%1, #16 * 0]\n\t"
+ asm volatile(".arch_extension fp\n\t"
+ "ldp q0, q1, [%1, #16 * 0]\n\t"
"ldp q2, q3, [%1, #16 * 2]\n\t"
"ldp q4, q5, [%1, #16 * 4]\n\t"
"ldp q6, q7, [%1, #16 * 6]\n\t"
@@ -46,6 +48,18 @@ static inline void restore_state(const uint64_t *fpregs)
: : "Q" (*fpregs), "r" (fpregs));
}
+#define WRITE_FP_SYSREG(v, name) do { \
+ uint64_t _r = (v); \
+ asm volatile(".arch_extension fp\n\t" \
+ "msr "__stringify(name)", %0" : : "r" (_r)); \
+} while (0)
+
+#define READ_FP_SYSREG(name) ({ \
+ uint64_t _r; \
+ asm volatile(".arch_extension fp\n\t" \
+ "mrs %0, "__stringify(name) : "=r" (_r)); \
+ _r; })
+
void vfp_save_state(struct vcpu *v)
{
if ( !cpu_has_fp )
@@ -56,10 +70,10 @@ void vfp_save_state(struct vcpu *v)
else
save_state(v->arch.vfp.fpregs);
- v->arch.vfp.fpsr = READ_SYSREG(FPSR);
- v->arch.vfp.fpcr = READ_SYSREG(FPCR);
+ v->arch.vfp.fpsr = READ_FP_SYSREG(FPSR);
+ v->arch.vfp.fpcr = READ_FP_SYSREG(FPCR);
if ( is_32bit_domain(v->domain) )
- v->arch.vfp.fpexc32_el2 = READ_SYSREG(FPEXC32_EL2);
+ v->arch.vfp.fpexc32_el2 = READ_FP_SYSREG(FPEXC32_EL2);
}
void vfp_restore_state(struct vcpu *v)
@@ -72,8 +86,8 @@ void vfp_restore_state(struct vcpu *v)
else
restore_state(v->arch.vfp.fpregs);
- WRITE_SYSREG(v->arch.vfp.fpsr, FPSR);
- WRITE_SYSREG(v->arch.vfp.fpcr, FPCR);
+ WRITE_FP_SYSREG(v->arch.vfp.fpsr, FPSR);
+ WRITE_FP_SYSREG(v->arch.vfp.fpcr, FPCR);
if ( is_32bit_domain(v->domain) )
- WRITE_SYSREG(v->arch.vfp.fpexc32_el2, FPEXC32_EL2);
+ WRITE_FP_SYSREG(v->arch.vfp.fpexc32_el2, FPEXC32_EL2);
}
--
2.49.0On 11.12.2025 13:57, Saman Dehghan wrote:
> --- a/xen/arch/arm/arm64/vfp.c
> +++ b/xen/arch/arm/arm64/vfp.c
> @@ -6,7 +6,8 @@
>
> static inline void save_state(uint64_t *fpregs)
> {
> - asm volatile("stp q0, q1, [%1, #16 * 0]\n\t"
> + asm volatile(".arch_extension fp\n\t"
This will take effect for the rest of the (generated) assembler file, which aiui
isn't what you want.
Jan
On Thu, Dec 11, 2025 at 7:50 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 11.12.2025 13:57, Saman Dehghan wrote:
> > --- a/xen/arch/arm/arm64/vfp.c
> > +++ b/xen/arch/arm/arm64/vfp.c
> > @@ -6,7 +6,8 @@
> >
> > static inline void save_state(uint64_t *fpregs)
> > {
> > - asm volatile("stp q0, q1, [%1, #16 * 0]\n\t"
> > + asm volatile(".arch_extension fp\n\t"
>
> This will take effect for the rest of the (generated) assembler file, which aiui
> isn't what you want.
Thanks Jan, I also noticed I forgot ".arch_extension nofp" just after
sending the patch. Sorry about that.
~Saman
>
> Jan
© 2016 - 2026 Red Hat, Inc.