From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] arm32: fix build after 063188f4b3 Date: Fri, 10 Oct 2014 15:12:30 +0100 Message-ID: <5437E94E.9010202@linaro.org> References: <54380211020000780003DC42@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xcavq-000696-Bu for xen-devel@lists.xenproject.org; Fri, 10 Oct 2014 14:12:34 +0000 Received: by mail-wi0-f179.google.com with SMTP id d1so2163735wiv.12 for ; Fri, 10 Oct 2014 07:12:32 -0700 (PDT) In-Reply-To: <54380211020000780003DC42@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , xen-devel Cc: Ian Campbell , Suriyan Ramasami , Stefano Stabellini , Tim Deegan List-Id: xen-devel@lists.xenproject.org Hi Jan, On 10/10/2014 14:58, Jan Beulich wrote: > "xen: arm: Add support for the Exynos secure firmware" introduced code > assuming that exynos_smc() would get called with arguments in certain > registers. While the "noinline" attribute guarantees the function to > not get inlined, it does not guarantee that all arguments arrive in the > assumed registers: gcc's interprocedural analysis can result in clone > functions to be created where some of the incoming arguments (commonly > when they have constant values) get replaced by putting in place the > respective values inside the clone. I'm not sure to understand here. If the function is marked as noinlined, that would mean the arguments will be passed with the ARM in the register with the ARM calling convention (i.e r0 for argument 0...). Why GCC would try to create a clone of this function? > The alternative of adding __attribute__((optimize("-fno-ipa-cp"))) > to the function definition would likely not work with all supported > compiler versions. The function was first introduced in arch/arm/psci.c (it's a copy of the Linux one in arch/arm/kernel/psci.c). Does it mean that Linux code is buggy too? > Signed-off-by: Jan Beulich > > --- a/xen/arch/arm/platforms/exynos5.c > +++ b/xen/arch/arm/platforms/exynos5.c > @@ -40,6 +40,11 @@ static bool_t secure_firmware; > static noinline void exynos_smc(register_t function_id, register_t arg0, > register_t arg1, register_t arg2) > { > + register register_t fn_id asm("r0") = function_id; > + register register_t a0 asm("r1") = arg0; > + register register_t a1 asm("r2") = arg1; > + register register_t a2 asm("r3") = arg2; > + > asm volatile( > __asmeq("%0", "r0") > __asmeq("%1", "r1") > @@ -47,7 +52,7 @@ static noinline void exynos_smc(register > __asmeq("%3", "r3") > "smc #0" > : > - : "r" (function_id), "r" (arg0), "r" (arg1), "r" (arg2)); > + : "r" (fn_id), "r" (a0), "r" (a1), "r" (a2)); > } This function is duplicate in 3 different places in Xen: - arch/arm/psci.c - arch/platforms/exynos5.c - arch/platforms/seattle.c So all those functions should be fixed. I think it's time to introduce a global SMC function... Regards, -- Julien Grall