Hi Stefano,
On 11/06/2022 01:41, Stefano Stabellini wrote:
#endif /* __ASSEMBLY__ */
/*
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 676740ef1520..6f90c08a6304 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -93,7 +93,7 @@ static bool handle_arch(struct cpu_user_regs *regs)
switch ( fid )
{
case ARM_SMCCC_VERSION_FID:
- set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+ set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_2);
return true;
This is going to be a problem for ARM32 given that ARM_SMCCC_VERSION_1_2
is unimplemented on ARM32. If there is an ARM32 implementation in Linux
for ARM_SMCCC_VERSION_1_2 you might as well import it too.
Otherwise we'll have to abstract it away, e.g.:
#ifdef CONFIG_ARM_64
#define ARM_VSMCCC_VERSION ARM_SMCCC_VERSION_1_2
#else
#define ARM_VSMCCC_VERSION ARM_SMCCC_VERSION_1_1
#endif
I don't understand why you want to tie the virtual and host SMCCC version.
In theory, it would be possible for us to implement a subsystem to fully
emulate, lets say, FFA. We would to tell the VM that we are v1.2
compliant but we would not need the helper as no calls would be forwarded.
When a 32-bit guest is running on Xen Arm64, we are going to say that
SMCCC v1.2 will be available. This is not much different from running a
32-bit guest on 32-bit hardware. So I think we should expose 1.2 unless
we think there is a problem in the Xen 32-bit specific code.
Cheers,
--
Julien Grall
