mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andrew Jones <drjones@redhat.com>,
	Hanjun Guo <guohanjun@huawei.com>,
	Jayachandran C <jnair@caviumnetworks.com>,
	Jon Masters <jcm@redhat.com>,
	Russell King - ARM Linux <linux@armlinux.org.uk>
Subject: Re: [PATCH v3 16/18] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
Date: Thu, 1 Feb 2018 14:18:00 +0000	[thread overview]
Message-ID: <135c00ef-2ee8-550e-afdd-8a217233b6c3@arm.com> (raw)
In-Reply-To: <0af501c9-2481-cb42-e1da-a884f7379942@arm.com>

On 01/02/18 13:54, Marc Zyngier wrote:
> On 01/02/18 13:34, Robin Murphy wrote:
>> On 01/02/18 11:46, Marc Zyngier wrote:
>>> One of the major improvement of SMCCC v1.1 is that it only clobbers
>>> the first 4 registers, both on 32 and 64bit. This means that it
>>> becomes very easy to provide an inline version of the SMC call
>>> primitive, and avoid performing a function call to stash the
>>> registers that would otherwise be clobbered by SMCCC v1.0.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> ---
>>>    include/linux/arm-smccc.h | 143 ++++++++++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 143 insertions(+)
>>>
>>> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
>>> index dd44d8458c04..575aabe85905 100644
>>> --- a/include/linux/arm-smccc.h
>>> +++ b/include/linux/arm-smccc.h
>>> @@ -150,5 +150,148 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1,
>>>    
>>>    #define arm_smccc_hvc_quirk(...) __arm_smccc_hvc(__VA_ARGS__)
>>>    
>>> +/* SMCCC v1.1 implementation madness follows */
>>> +#ifdef CONFIG_ARM64
>>> +
>>> +#define SMCCC_SMC_INST	"smc	#0"
>>> +#define SMCCC_HVC_INST	"hvc	#0"
>>
>> Nit: Maybe the argument can go in the template and we just define the
>> instruction mnemonics here?
>>
>>> +
>>> +#endif
>>> +
>>> +#ifdef CONFIG_ARM
>>
>> #elif ?
> 
> Sure, why not.
> 
>>
>>> +#include <asm/opcodes-sec.h>
>>> +#include <asm/opcodes-virt.h>
>>> +
>>> +#define SMCCC_SMC_INST	__SMC(0)
>>> +#define SMCCC_HVC_INST	__HVC(0)
>>
>> Oh, I see, it was to line up with this :(
>>
>> I do wonder if we could just embed an asm(".arch armv7-a+virt\n") (if
>> even necessary) for ARM, then take advantage of the common mnemonics for
>> all 3 instruction sets instead of needing manual encoding tricks? I
>> don't think we should ever be pulling this file in for non-v7 builds.
>>
>> I suppose that strictly that appears to need binutils 2.21 rather than
>> the offical supported minimum of 2.20, but are people going to be
>> throwing SMCCC configs at antique toolchains in practice?
> 
> It has been an issue in the past, back when we merged KVM. We settled on
> a hybrid solution where code outside of KVM would not rely on a newer
> toolchain, hence the macros that Dave introduced. Maybe we've moved on
> and we can take that bold step?

Either way I think we can happily throw that on the "future cleanup" 
pile right now as it's not directly relevant to the purpose of the 
patch; I'm sure we don't want to make potential backporting even more 
difficult.

>>
>>> +
>>> +#endif
>>> +
>>> +#define ___count_args(_0, _1, _2, _3, _4, _5, _6, _7, _8, x, ...) x
>>> +
>>> +#define __count_args(...)						\
>>> +	___count_args(__VA_ARGS__, 7, 6, 5, 4, 3, 2, 1, 0)
>>> +
>>> +#define __constraint_write_0						\
>>> +	"+r" (r0), "=&r" (r1), "=&r" (r2), "=&r" (r3)
>>> +#define __constraint_write_1						\
>>> +	"+r" (r0), "+r" (r1), "=&r" (r2), "=&r" (r3)
>>> +#define __constraint_write_2						\
>>> +	"+r" (r0), "+r" (r1), "+r" (r2), "=&r" (r3)
>>> +#define __constraint_write_3						\
>>> +	"+r" (r0), "+r" (r1), "+r" (r2), "+r" (r3)
>>> +#define __constraint_write_4	__constraint_write_3
>>> +#define __constraint_write_5	__constraint_write_4
>>> +#define __constraint_write_6	__constraint_write_5
>>> +#define __constraint_write_7	__constraint_write_6
>>> +
>>> +#define __constraint_read_0
>>> +#define __constraint_read_1
>>> +#define __constraint_read_2
>>> +#define __constraint_read_3
>>> +#define __constraint_read_4	"r" (r4)
>>> +#define __constraint_read_5	__constraint_read_4, "r" (r5)
>>> +#define __constraint_read_6	__constraint_read_5, "r" (r6)
>>> +#define __constraint_read_7	__constraint_read_6, "r" (r7)
>>> +
>>> +#define __declare_arg_0(a0, res)					\
>>> +	struct arm_smccc_res   *___res = res;				\
>>
>> Looks like the declaration of ___res could simply be factored out to the
>> template...
> 
> Tried that. But...
> 
>>
>>> +	register u32           r0 asm("r0") = a0;			\
>>> +	register unsigned long r1 asm("r1");				\
>>> +	register unsigned long r2 asm("r2");				\
>>> +	register unsigned long r3 asm("r3")
>>> +
>>> +#define __declare_arg_1(a0, a1, res)					\
>>> +	struct arm_smccc_res   *___res = res;				\
>>> +	register u32           r0 asm("r0") = a0;			\
>>> +	register typeof(a1)    r1 asm("r1") = a1;			\
>>> +	register unsigned long r2 asm("r2");				\
>>> +	register unsigned long r3 asm("r3")
>>> +
>>> +#define __declare_arg_2(a0, a1, a2, res)				\
>>> +	struct arm_smccc_res   *___res = res;				\
>>> +	register u32           r0 asm("r0") = a0;			\
>>> +	register typeof(a1)    r1 asm("r1") = a1;			\
>>> +	register typeof(a2)    r2 asm("r2") = a2;			\
>>> +	register unsigned long r3 asm("r3")
>>> +
>>> +#define __declare_arg_3(a0, a1, a2, a3, res)				\
>>> +	struct arm_smccc_res   *___res = res;				\
>>> +	register u32           r0 asm("r0") = a0;			\
>>> +	register typeof(a1)    r1 asm("r1") = a1;			\
>>> +	register typeof(a2)    r2 asm("r2") = a2;			\
>>> +	register typeof(a3)    r3 asm("r3") = a3
>>> +
>>> +#define __declare_arg_4(a0, a1, a2, a3, a4, res)			\
>>> +	__declare_arg_3(a0, a1, a2, a3, res);				\
>>> +	register typeof(a4) r4 asm("r4") = a4
>>> +
>>> +#define __declare_arg_5(a0, a1, a2, a3, a4, a5, res)			\
>>> +	__declare_arg_4(a0, a1, a2, a3, a4, res);			\
>>> +	register typeof(a5) r5 asm("r5") = a5
>>> +
>>> +#define __declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res)		\
>>> +	__declare_arg_5(a0, a1, a2, a3, a4, a5, res);			\
>>> +	register typeof(a6) r6 asm("r6") = a6
>>> +
>>> +#define __declare_arg_7(a0, a1, a2, a3, a4, a5, a6, a7, res)		\
>>> +	__declare_arg_6(a0, a1, a2, a3, a4, a5, a6, res);		\
>>> +	register typeof(a7) r7 asm("r7") = a7
>>> +
>>> +#define ___declare_args(count, ...) __declare_arg_ ## count(__VA_ARGS__)
>>> +#define __declare_args(count, ...)  ___declare_args(count, __VA_ARGS__)
>>> +
>>> +#define ___constraints(count)						\
>>> +	: __constraint_write_ ## count					\
>>> +	: __constraint_read_ ## count					\
>>> +	: "memory"
>>> +#define __constraints(count)	___constraints(count)
>>> +
>>> +/*
>>> + * We have an output list that is not necessarily used, and GCC feels
>>> + * entitled to optimise the whole sequence away. "volatile" is what
>>> + * makes it stick.
>>> + */
>>> +#define __arm_smccc_1_1(inst, ...)					\
>>> +	do {								\
>>> +		__declare_args(__count_args(__VA_ARGS__), __VA_ARGS__);	\
>>> +		asm volatile(inst "\n"					\
>>> +			     __constraints(__count_args(__VA_ARGS__)));	\
>>> +		if (___res)						\
>>> +			*___res = (typeof(*___res)){r0, r1, r2, r3};	\
>>
>> ...especially since there's no obvious indication of where it comes from
>> when you're looking here.
> 
> ... we don't have the variable name at all here (it is the last
> parameter, and that doesn't quite work with the idea of variadic macros...).
> 
> The alternative would be to add a set of macros that return the result
> parameter, based on the number of inputs. Not sure that's an improvement.

Ah, right, the significance of it being the *last* argument hadn't 
clicked indeed. A whole barrage of extra macros just to extract res on 
its own would be rather clunky, so let's just keep the nice streamlined 
(if ever-so-slightly non-obvious) implementation as it is and ignore my 
ramblings.

Robin.

  reply	other threads:[~2018-02-01 14:18 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 11:46 [PATCH v3 00/18] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation Marc Zyngier
2018-02-01 11:46 ` [PATCH v3 01/18] arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls Marc Zyngier
2018-02-01 11:46 ` [PATCH v3 02/18] arm: " Marc Zyngier
2018-02-01 11:46 ` [PATCH v3 03/18] arm64: KVM: Increment PC after handling an SMC trap Marc Zyngier
2018-02-02 12:33   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 04/18] arm/arm64: KVM: Consolidate the PSCI include files Marc Zyngier
2018-02-02 12:33   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 05/18] arm/arm64: KVM: Add PSCI_VERSION helper Marc Zyngier
2018-02-02 12:33   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 06/18] arm/arm64: KVM: Add smccc accessors to PSCI code Marc Zyngier
2018-02-02 12:33   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 07/18] arm/arm64: KVM: Implement PSCI 1.0 support Marc Zyngier
2018-02-02 12:33   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 08/18] arm/arm64: KVM: Add PSCI version selection API Marc Zyngier
2018-02-02 20:17   ` Andrew Jones
2018-02-03 11:59     ` Marc Zyngier
2018-02-04 12:37       ` Christoffer Dall
2018-02-05  9:24         ` Marc Zyngier
2018-02-05  9:58           ` Andrew Jones
2018-02-05 10:42             ` Marc Zyngier
2018-02-05 10:50               ` Christoffer Dall
2018-02-05 11:08                 ` Marc Zyngier
2018-02-05  9:47         ` Andrew Jones
2018-02-05  9:25       ` Andrew Jones
2018-02-04 12:38   ` Christoffer Dall
2018-02-05  9:30     ` Marc Zyngier
2018-02-01 11:46 ` [PATCH v3 09/18] arm/arm64: KVM: Advertise SMCCC v1.1 Marc Zyngier
2018-02-04 18:38   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 10/18] arm/arm64: KVM: Turn kvm_psci_version into a static inline Marc Zyngier
2018-02-04 18:38   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 11/18] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support Marc Zyngier
2018-02-04 18:39   ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 12/18] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling Marc Zyngier
2018-02-04 18:39   ` Christoffer Dall
2018-02-05  9:08     ` Marc Zyngier
2018-02-05 10:18       ` Christoffer Dall
2018-02-01 11:46 ` [PATCH v3 13/18] firmware/psci: Expose PSCI conduit Marc Zyngier
2018-02-01 12:25   ` Robin Murphy
2018-02-01 11:46 ` [PATCH v3 14/18] firmware/psci: Expose SMCCC version through psci_ops Marc Zyngier
2018-02-01 12:32   ` Robin Murphy
2018-02-01 12:48     ` Marc Zyngier
2018-02-01 21:17   ` Ard Biesheuvel
2018-02-01 11:46 ` [PATCH v3 15/18] arm/arm64: smccc: Make function identifiers an unsigned quantity Marc Zyngier
2018-02-01 12:40   ` Robin Murphy
2018-02-01 12:44     ` Ard Biesheuvel
2018-02-01 11:46 ` [PATCH v3 16/18] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive Marc Zyngier
2018-02-01 13:34   ` Robin Murphy
2018-02-01 13:54     ` Marc Zyngier
2018-02-01 14:18       ` Robin Murphy [this message]
2018-02-01 11:46 ` [PATCH v3 17/18] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support Marc Zyngier
2018-02-01 11:46 ` [PATCH v3 18/18] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround Marc Zyngier
2018-02-02  4:05   ` Hanjun Guo
2018-02-02 13:17     ` Marc Zyngier
2018-02-01 13:59 ` [PATCH v3 00/18] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation Ard Biesheuvel
2018-02-01 14:20   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=135c00ef-2ee8-550e-afdd-8a217233b6c3@arm.com \
    --to=robin.murphy@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=drjones@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=jcm@redhat.com \
    --cc=jnair@caviumnetworks.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=peter.maydell@linaro.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome