Re: [Xen-devel] [[PATCH v3] 4/4] xen/arm: Replace call_smc with arm_smccc_smc

[Julien Grall]

Hi Andrew,

On 10/01/2018 02:11 PM, Andrew Cooper wrote:
On 01/10/18 13:46, Julien Grall wrote:
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to
do SMCCC call, replace all call to the former by the later.
Signed-off-by: Julien Grall <julien.gr...@arm.com>

---

     Changes in v3:
         - Use PSCI_RET where needed
---
  xen/arch/arm/Makefile            |  1 -
  xen/arch/arm/platforms/exynos5.c |  3 ++-
  xen/arch/arm/platforms/seattle.c |  4 ++--
  xen/arch/arm/psci.c              | 37 +++++++++++++++++++++++++------------
  xen/arch/arm/smc.S               | 21 ---------------------
  xen/include/asm-arm/processor.h  |  3 ---
  6 files changed, 29 insertions(+), 40 deletions(-)
  delete mode 100644 xen/arch/arm/smc.S

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b9b141dc84..37fa8268b3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,7 +39,6 @@ obj-y += processor.o
  obj-y += psci.o
  obj-y += setup.o
  obj-y += shutdown.o
-obj-y += smc.o
  obj-y += smp.o
  obj-y += smpboot.o
  obj-y += sysctl.o
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index c15ecf80f5..e2c0b7b878 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -26,6 +26,7 @@
  #include <asm/platforms/exynos5.h>
  #include <asm/platform.h>
  #include <asm/io.h>
+#include <asm/smccc.h>
  
  static bool secure_firmware;
  
@@ -249,7 +250,7 @@ static int exynos5_cpu_up(int cpu)
      iounmap(power);
  
      if ( secure_firmware )
-        call_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
+        arm_smccc_smc(SMC_CMD_CPU1BOOT, cpu, NULL);
  
      return cpu_up_send_sgi(cpu);
  }
diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 893cc17972..64cc1868c2 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst =
   */
  static void seattle_system_reset(void)
  {
-    call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
+    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_RESET, NULL);
  }
  
  static void seattle_system_off(void)
  {
-    call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
+    arm_smccc_smc(PSCI_0_2_FN32_SYSTEM_OFF, NULL);
  }
  
  PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 941eec921b..4ae6504f3e 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -42,42 +42,53 @@ uint32_t smccc_ver;
  
  static uint32_t psci_cpu_on_nr;
  
+#define PSCI_RET(res)   ((int32_t)(res).a0)
+
  int call_psci_cpu_on(int cpu)
  {
-    return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu), 
__pa(init_secondary), 0);
+    struct arm_smccc_res res;
+
+    arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu), __pa(init_secondary),
+                  &res);
+
+    return PSCI_RET(res.a0);
  }

Sorry if I'm jumping into the middle of a conversation, but why force
all callers to manually extract the return value when it is a fixed
register?

The SMCCC allows up to 4 return value (a0 ... a3). At the moment, most 
of the caller in Xen only care about one result value. But this will 
change soon (see OP-TEE support in Xen).


Wouldn't it be far easier to do this:

#define arcm_smccc_smc(...)                         \
     ({                                              \
         struct arm_smccc_res res;                   \
                                                     \
         if ( cpus_have_const_cap(ARM_SMCCC_1_1) )   \
             res = arm_smccc_1_1_smc(__VA_ARGS__);   \
         else                                        \
             res = arm_smccc_1_0_smc(__VA_ARGS__);   \
                                                     \
         (int)res.a0;                                \

We can't possibly cast here. The interpretation of a0 is different from 
one call to another.

     })

Which also allows the compiler to optimise out the structure if it isn't
read, and also avoids the caller needing to pass a NULL pointer for "I
don't want the result".

While I understand the value, I don't think this would be correct if we 
want to implement an interface with the SMCCC.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel