* [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Ilias Apalodimas @ 2018-05-24 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f73b4a0e-669e-8483-88d7-1b2c8a2b9934@arm.com>
> Interesting, I hadn't thought about this use-case before. At first I
> thought you were talking about mdev devices assigned to VMs, but I think
> you're referring to mdevs assigned to userspace drivers instead? Out of
> curiosity, is it only theoretical or does someone actually need this?
There has been some non upstreamed efforts to have mdev and produce userspace
drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and
we did a proof of concept for ethernet interfaces. At the time we choose not to
involve the IOMMU for the reason you mentioned, but having it there would be
good.
Thanks
Ilias
^ permalink raw reply
* [PATCH 05/14] arm64: Add 'ssbd' command-line option
From: Marc Zyngier @ 2018-05-24 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524114031.ehtumruiyuu4z2oo@lakrids.cambridge.arm.com>
On 24/05/18 12:40, Mark Rutland wrote:
> On Tue, May 22, 2018 at 04:06:39PM +0100, Marc Zyngier wrote:
>> On a system where the firmware implements ARCH_WORKAROUND_2,
>> it may be useful to either permanently enable or disable the
>> workaround for cases where the user decides that they'd rather
>> not get a trap overhead, and keep the mitigation permanently
>> on or off instead of switching it on exception entry/exit.
>>
>> In any case, default to the mitigation being enabled.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 17 ++++
>> arch/arm64/include/asm/cpufeature.h | 6 ++
>> arch/arm64/kernel/cpu_errata.c | 102 ++++++++++++++++++++----
>> 3 files changed, 109 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index f2040d46f095..646e112c6f63 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4092,6 +4092,23 @@
>> expediting. Set to zero to disable automatic
>> expediting.
>>
>> + ssbd= [ARM64,HW]
>> + Speculative Store Bypass Disable control
>> +
>> + On CPUs that are vulnerable to the Speculative
>> + Store Bypass vulnerability and offer a
>> + firmware based mitigation, this parameter
>> + indicates how the mitigation should be used:
>> +
>> + force-on: Unconditionnaly enable mitigation for
>> + for both kernel and userspace
>> + force-off: Unconditionnaly disable mitigation for
>> + for both kernel and userspace
>> + kernel: Always enable mitigation in the
>> + kernel, and offer a prctl interface
>> + to allow userspace to register its
>> + interest in being mitigated too.
>> +
>> stack_guard_gap= [MM]
>> override the default stack gap protection. The value
>> is in page units and it defines how many pages prior
>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>> index 09b0f2a80c8f..9bc548e22784 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -537,6 +537,12 @@ static inline u64 read_zcr_features(void)
>> return zcr;
>> }
>>
>> +#define ARM64_SSBD_UNKNOWN -1
>> +#define ARM64_SSBD_FORCE_DISABLE 0
>> +#define ARM64_SSBD_EL1_ENTRY 1
>
> The EL1_ENTRY part of the name is a bit misleading, since this doesn't
> apply to EL1->EL1 exceptions (and as with many other bits of the arm64
> code, it's arguably misleading in the VHE case).
>
> Perhaps ARM64_SSBD_KERNEL, which would align with the parameter name?
I was just waiting for someone to sort out the naming for me, thanks for
falling into that trap! ;-)
I'll update that.
> Not a big deal either way, and otherwise this looks good to me.
> Regardless:
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 08/14] arm64: ssbd: Disable mitigation on CPU resume if required by user
From: Mark Rutland @ 2018-05-24 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-9-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:42PM +0100, Marc Zyngier wrote:
> On a system where firmware can dynamically change the state of the
> mitigation, the CPU will always come up with the mitigation enabled,
> including when coming back from suspend.
>
> If the user has requested "no mitigation" via a command line option,
> let's enforce it by calling into the firmware again to disable it.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/cpufeature.h | 6 ++++++
> arch/arm64/kernel/cpu_errata.c | 8 ++++----
> arch/arm64/kernel/suspend.c | 8 ++++++++
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 1bacdf57f0af..d9dcb683259e 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -553,6 +553,12 @@ static inline int arm64_get_ssbd_state(void)
> #endif
> }
>
> +#ifdef CONFIG_ARM64_SSBD
> +void arm64_set_ssbd_mitigation(bool state);
> +#else
> +static inline void arm64_set_ssbd_mitigation(bool state) {}
> +#endif
> +
> #endif /* __ASSEMBLY__ */
>
> #endif
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 8f686f39b9c1..b4c12e9140f0 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -297,7 +297,7 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt,
> *updptr = cpu_to_le32(aarch64_insn_gen_nop());
> }
>
> -static void do_ssbd(bool state)
> +void arm64_set_ssbd_mitigation(bool state)
Using this name from the outset would be nice, if you're happy to fold
that earlier in the seires. Not a big deal either way.
> {
> switch (psci_ops.conduit) {
> case PSCI_CONDUIT_HVC:
> @@ -371,20 +371,20 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> switch (ssbd_state) {
> case ARM64_SSBD_FORCE_DISABLE:
> pr_info_once("%s disabled from command-line\n", entry->desc);
> - do_ssbd(false);
> + arm64_set_ssbd_mitigation(false);
> required = false;
> break;
>
> case ARM64_SSBD_EL1_ENTRY:
> if (required) {
> __this_cpu_write(arm64_ssbd_callback_required, 1);
> - do_ssbd(true);
> + arm64_set_ssbd_mitigation(true);
> }
> break;
>
> case ARM64_SSBD_FORCE_ENABLE:
> pr_info_once("%s forced from command-line\n", entry->desc);
> - do_ssbd(true);
> + arm64_set_ssbd_mitigation(true);
> required = true;
> break;
>
> diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
> index a307b9e13392..70c283368b64 100644
> --- a/arch/arm64/kernel/suspend.c
> +++ b/arch/arm64/kernel/suspend.c
> @@ -62,6 +62,14 @@ void notrace __cpu_suspend_exit(void)
> */
> if (hw_breakpoint_restore)
> hw_breakpoint_restore(cpu);
> +
> + /*
> + * On resume, firmware implementing dynamic mitigation will
> + * have turned the mitigation on. If the user has forcefully
> + * disabled it, make sure their wishes are obeyed.
> + */
> + if (arm64_get_ssbd_state() == ARM64_SSBD_FORCE_DISABLE)
> + arm64_set_ssbd_mitigation(false);
> }
This looks fine for idle and suspend-to-ram, so:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
However, for suspend-to-disk (i.e hibernate), the kernel doing the
resume might have SSBD force-disabled, while this kernel (which has just
been resumed) wants it enabled.
I think we also need something in swsusp_arch_suspend(), right after the
call to __cpu_suspend_exit() to re-enable that.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 09/14] arm64: ssbd: Introduce thread flag to control userspace mitigation
From: Mark Rutland @ 2018-05-24 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-10-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:43PM +0100, Marc Zyngier wrote:
> In order to allow userspace to be mitigated on demand, let's
> introduce a new thread flag that prevents the mitigation from
> being turned off when exiting to userspace, and doesn't turn
> it on on entry into the kernel (with the assumtion that the
Nit: s/assumtion/assumption/
> mitigation is always enabled in the kernel itself).
>
> This will be used by a prctl interface introduced in a later
> patch.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
On the assumption that this flag cannot be flipped while a task is in
userspace:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/include/asm/thread_info.h | 1 +
> arch/arm64/kernel/entry.S | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
> index 740aa03c5f0d..cbcf11b5e637 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -94,6 +94,7 @@ void arch_release_task_struct(struct task_struct *tsk);
> #define TIF_32BIT 22 /* 32bit process */
> #define TIF_SVE 23 /* Scalable Vector Extension in use */
> #define TIF_SVE_VL_INHERIT 24 /* Inherit sve_vl_onexec across exec */
> +#define TIF_SSBD 25 /* Wants SSB mitigation */
>
> #define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
> #define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index e6f6e2339b22..28ad8799406f 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -147,6 +147,8 @@ alternative_cb arm64_enable_wa2_handling
> alternative_cb_end
> ldr_this_cpu \tmp2, arm64_ssbd_callback_required, \tmp1
> cbz \tmp2, \targ
> + ldr \tmp2, [tsk, #TSK_TI_FLAGS]
> + tbnz \tmp2, #TIF_SSBD, \targ
> mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2
> mov w1, #\state
> alternative_cb arm64_update_smccc_conduit
> --
> 2.14.2
>
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Marc Zyngier @ 2018-05-24 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523194503.GX17671@n2100.armlinux.org.uk>
On 23/05/18 20:45, Russell King - ARM Linux wrote:
> On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
>> On 21/05/18 12:45, Russell King wrote:
>>> +#ifdef CONFIG_ARM_PSCI
>>> + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
>>> + struct arm_smccc_res res;
>>> +
>>> + switch (psci_ops.conduit) {
>>> + case PSCI_CONDUIT_HVC:
>>> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>>> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
>>> + if ((int)res.a0 < 0)
>>> + break;
>>
>> I just realised that there is a small, but significant difference
>> between this and the arm64 version: On arm64, we have a table of
>> vulnerable implementations, and we try the mitigation on a per-cpu
>> basis. Here, you entirely rely on the firmware to discover whether the
>> CPU needs mitigation or not. You then need to check for a return value
>> of 1, which indicates that although the mitigation is implemented, it is
>> not required on this particular CPU.
>
> Okay, so digging further into the documentation seems to suggest that we
> only need to check the firmware for A72 and A57 CPUs, and given this
> statement:
>
> "Arm recommends that the caller only call this on PEs for which a
> firmware based mitigation of CVE-2017-5715 is required, or where
> a local workaround is infeasible."
>
> it seems that the right answer is to ignore the PSCI based methods when
> we have anything but these CPUs. Do you agree?
For CPUs that are produced by ARM, I agree. I don't know about CPUs
produced by ARM licensees though, so I'd rather use the opposite logic:
Use the firmware unless the CPU is one of those that can be easily
mitigated at EL1 (or isn't affected).
>> But that's probably moot if you don't support BL systems.
>
> Any bL systems with A72 or A57?
Juno is a canonical example of such a system (either 2xA57+4xA53, or
2xA72+4xA53), and there is plenty of partner's silicon in the wild.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Heiko Stuebner @ 2018-05-24 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+VBspzCaLD2Wy=fyC-S+LKGZbVsB+b+Etkx91ioXOCuQ@mail.gmail.com>
Hi Rob,
Am Mittwoch, 23. Mai 2018, 21:53:53 CEST schrieb Rob Herring:
> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
> > Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
> >> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> >> > On 2018-05-23 2:02 AM, Rob Herring wrote:
> >> >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
> >> >>> From: Levin Du <djw@t-chip.com.cn>
> >> >>>
> >> >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> >> >>> which do not belong to the general pinctrl.
> >> >>>
> >> >>> Adding gpio-syscon support makes controlling regulator or
> >> >>> LED using these special pins very easy by reusing existing
> >> >>> drivers, such as gpio-regulator and led-gpio.
> >> >>>
> >> >>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
> >> >>>
> >> >>> ---
> >> >>>
> >> >>> Changes in v2:
> >> >>> - Rename gpio_syscon10 to gpio_mute in doc
> >> >>>
> >> >>> Changes in v1:
> >> >>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> >> >>> - Add doc rockchip,gpio-syscon.txt
> >> >>>
> >> >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
> >> >>>
> >> >>> ++++++++++++++++++++++
> >> >>>
> >> >>> drivers/gpio/gpio-syscon.c | 30
> >> >>>
> >> >>> ++++++++++++++++
> >> >>>
> >> >>> 2 files changed, 71 insertions(+)
> >> >>> create mode 100644
> >> >>>
> >> >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >> >>>
> >> >>> diff --git
> >> >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >> >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >> >>> new file mode 100644
> >> >>> index 0000000..b1b2a67
> >> >>> --- /dev/null
> >> >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >> >>> @@ -0,0 +1,41 @@
> >> >>> +* Rockchip GPIO support for GRF_SOC_CON registers
> >> >>> +
> >> >>> +Required properties:
> >> >>> +- compatible: Should contain "rockchip,gpio-syscon".
> >> >>> +- gpio-controller: Marks the device node as a gpio controller.
> >> >>> +- #gpio-cells: Should be two. The first cell is the pin number and
> >> >>> + the second cell is used to specify the gpio polarity:
> >> >>> + 0 = Active high,
> >> >>> + 1 = Active low.
> >> >>
> >> >> There's no need for this child node. Just make the parent node a gpio
> >> >> controller.
> >> >>
> >> >> Rob
> >> >
> >> > Hi Rob, it is not clear to me. Do you suggest that the grf node should be
> >> > a
> >> > gpio controller,
> >> > like below?
> >> >
> >> > + grf: syscon at ff100000 {
> >> > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> >> > "syscon", "simple-mfd";
> >>
> >> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
> >
> > I would disagree quite a bit here. The grf are the "general register files",
> > a bunch of registers used for quite a lot of things, and so it seems
> > among other users, also a gpio-controller for some more random pins
> > not controlled through the regular gpio controllers.
> >
> > For a more fully stocked grf, please see
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
> >
> > So the gpio controller should definitly also be a subnode.
>
> Sigh, yes, if there are a bunch of functions needing subnodes like the
> above, then yes that makes sense. But that's not what has been
> presented. Please make some attempt at defining *all* the functions.
> An actual binding would be nice, but I'll settle for just a list of
> things. The list should have functions that have DT dependencies (like
> clocks for phys in the above) because until you do, you don't need
> child nodes.
That's the problem with the Rockchip-GRF, you only realize its content
when implementing specific features.
Like on the rk3399 the table of the register-list of the GRF alone is 11
pages long with the register details tables taking up another 230 pages.
And functional description is often somewhat thin.
So I'm not sure I fully understand what you're asking, but in general
we define the bindings for sub-devices when tackling these individual
components, see for example
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=72580a49a837c2c7da83f698c00592eac41537d8
which also has a real phy-driver behind it and binding against that
subnode of the GRF simple-mfd.
These are real IP blocks somewhere on the socs, with regular supplies
like resets, clocks etc in most cases. Only their controlling registers
got dumped into the GRF for some reason.
And in retrospect it really looks like we're doing something right,
because it seems these bindings seem quite stable over time.
> > The gpio in question is called "mute", so I'd think the gpio-syscon driver
> > should just define a "rockchip,rk3328-gpio-mute" compatible and contain
> > all the register voodoo in the driver itself and not define it in the dt.
>
> Is there really just one GPIO? If it has a defined function, then is
> it really GP? Can you control direction? I know Linus W doesn't like
> that kind of abuse of GPIO.
looks like I convinced Linus that we're not abusing anything with this :-) .
Heiko
^ permalink raw reply
* [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation
From: Mark Rutland @ 2018-05-24 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-11-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote:
> If running on a system that performs dynamic SSBD mitigation, allow
> userspace to request the mitigation for itself. This is implemented
> as a prctl call, allowing the mitigation to be enabled or disabled at
> will for this particular thread.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/ssbd.c | 107 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 108 insertions(+)
> create mode 100644 arch/arm64/kernel/ssbd.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index bf825f38d206..0025f8691046 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -54,6 +54,7 @@ arm64-obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
> arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
> arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
> +arm64-obj-$(CONFIG_ARM64_SSBD) += ssbd.o
>
> obj-y += $(arm64-obj-y) vdso/ probes/
> obj-m += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/ssbd.c b/arch/arm64/kernel/ssbd.c
> new file mode 100644
> index 000000000000..34e3c430176b
> --- /dev/null
> +++ b/arch/arm64/kernel/ssbd.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 ARM Ltd, All Rights Reserved.
> + */
> +
#include <linux/errno.h>
... for the error numbers you return below.
> +#include <linux/sched.h>
> +#include <linux/thread_info.h>
> +
> +#include <asm/cpufeature.h>
> +
> +/*
> + * prctl interface for SSBD
> + * FIXME: Drop the below ifdefery once the common interface has been merged.
> + */
> +#ifdef PR_SPEC_STORE_BYPASS
> +static int ssbd_prctl_set(struct task_struct *task, unsigned long ctrl)
> +{
> + int state = arm64_get_ssbd_state();
> +
> + /* Unsupported or already mitigated */
> + if (state == ARM64_SSBD_UNKNOWN)
> + return -EINVAL;
> + if (state == ARM64_SSBD_MITIGATED)
> + return -EPERM;
> +
> + /*
> + * Things are a bit backward here: the arm64 internal API
> + * *enables the mitigation* when the userspace API *disables
> + * speculation*. So much fun.
> + */
> + switch (ctrl) {
> + case PR_SPEC_ENABLE:
> + /* If speculation is force disabled, enable is not allowed */
> + if (state == ARM64_SSBD_FORCE_ENABLE ||
> + task_spec_ssb_force_disable(task))
> + return -EPERM;
> + task_clear_spec_ssb_disable(task);
> + clear_tsk_thread_flag(task, TIF_SSBD);
> + break;
> + case PR_SPEC_DISABLE:
> + if (state == ARM64_SSBD_FORCE_DISABLE)
> + return -EPERM;
> + task_set_spec_ssb_disable(task);
> + set_tsk_thread_flag(task, TIF_SSBD);
> + break;
> + case PR_SPEC_FORCE_DISABLE:
> + if (state == ARM64_SSBD_FORCE_DISABLE)
> + return -EPERM;
> + task_set_spec_ssb_disable(task);
> + task_set_spec_ssb_force_disable(task);
> + set_tsk_thread_flag(task, TIF_SSBD);
> + break;
> + default:
> + return -ERANGE;
> + }
> +
> + return 0;
> +}
I'll have to take a look at the core implementation to make sense of
the rest.
Mark.
^ permalink raw reply
* [PATCH 02/14] arm64: Call ARCH_WORKAROUND_2 on transitions between EL0 and EL1
From: Robin Murphy @ 2018-05-24 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524105205.rq25srimaceo3ov4@lakrids.cambridge.arm.com>
On 24/05/18 11:52, Mark Rutland wrote:
> On Wed, May 23, 2018 at 10:23:20AM +0100, Julien Grall wrote:
>> Hi Marc,
>>
>> On 05/22/2018 04:06 PM, Marc Zyngier wrote:
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index ec2ee720e33e..f33e6aed3037 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -18,6 +18,7 @@
>>> * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>> */
>>> +#include <linux/arm-smccc.h>
>>> #include <linux/init.h>
>>> #include <linux/linkage.h>
>>> @@ -137,6 +138,18 @@ alternative_else_nop_endif
>>> add \dst, \dst, #(\sym - .entry.tramp.text)
>>> .endm
>>> + // This macro corrupts x0-x3. It is the caller's duty
>>> + // to save/restore them if required.
>>
>> NIT: Shouldn't you use /* ... */ for multi-line comments?
>
> There's no requirement to do so, and IIRC even Torvalds prefers '//'
> comments for multi-line things these days.
Also, this is an assembly code, not C; '//' is the actual A64 assembler
comment syntax so is arguably more appropriate here in spite of being
moot thanks to preprocessing.
Robin.
^ permalink raw reply
* [PATCH 11/14] arm64: KVM: Add HYP per-cpu accessors
From: Mark Rutland @ 2018-05-24 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-12-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:45PM +0100, Marc Zyngier wrote:
> As we're going to require to access per-cpu variables at EL2,
> let's craft the minimum set of accessors required to implement
> reading a per-cpu variable, relying on tpidr_el2 to contain the
> per-cpu offset.
>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/include/asm/kvm_asm.h | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index f6648a3e4152..fefd8cf42c35 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -71,14 +71,37 @@ extern u32 __kvm_get_mdcr_el2(void);
>
> extern u32 __init_stage2_translation(void);
>
> +/* Home-grown __this_cpu_{ptr,read} variants that always work at HYP */
> +#define __hyp_this_cpu_ptr(sym) \
> + ({ \
> + void *__ptr = hyp_symbol_addr(sym); \
> + __ptr += read_sysreg(tpidr_el2); \
> + (typeof(&sym))__ptr; \
> + })
> +
> +#define __hyp_this_cpu_read(sym) \
> + ({ \
> + *__hyp_this_cpu_ptr(sym); \
> + })
> +
> #else /* __ASSEMBLY__ */
>
> -.macro get_host_ctxt reg, tmp
> - adr_l \reg, kvm_host_cpu_state
> +.macro hyp_adr_this_cpu reg, sym, tmp
> + adr_l \reg, \sym
> mrs \tmp, tpidr_el2
> add \reg, \reg, \tmp
> .endm
>
> +.macro hyp_ldr_this_cpu reg, sym, tmp
> + adr_l \reg, \sym
> + mrs \tmp, tpidr_el2
> + ldr \reg, [\reg, \tmp]
> +.endm
> +
> +.macro get_host_ctxt reg, tmp
> + hyp_adr_this_cpu \reg, kvm_host_cpu_state, \tmp
> +.endm
> +
> .macro get_vcpu_ptr vcpu, ctxt
> get_host_ctxt \ctxt, \vcpu
> ldr \vcpu, [\ctxt, #HOST_CONTEXT_VCPU]
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 12/14] arm64: KVM: Add ARCH_WORKAROUND_2 support for guests
From: Mark Rutland @ 2018-05-24 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-13-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:46PM +0100, Marc Zyngier wrote:
> In order to offer ARCH_WORKAROUND_2 support to guests, we need
> a bit of infrastructure.
>
> Let's add a flag indicating whether or not the guest uses
> SSBD mitigation. Depending on the state of this flag, allow
> KVM to disable ARCH_WORKAROUND_2 before entering the guest,
> and enable it when exiting it.
>
> Reviewed-by: Christoffer Dall <christoffer.dall@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/include/asm/kvm_mmu.h | 5 +++++
> arch/arm64/include/asm/kvm_asm.h | 3 +++
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/include/asm/kvm_mmu.h | 24 ++++++++++++++++++++++
> arch/arm64/kvm/hyp/switch.c | 42 +++++++++++++++++++++++++++++++++++++++
> virt/kvm/arm/arm.c | 4 ++++
> 6 files changed, 81 insertions(+)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 707a1f06dc5d..b0c17d88ed40 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -319,6 +319,11 @@ static inline int kvm_map_vectors(void)
> return 0;
> }
>
> +static inline int hyp_map_aux_data(void)
> +{
> + return 0;
> +}
> +
> #define kvm_phys_to_vttbr(addr) (addr)
>
> #endif /* !__ASSEMBLY__ */
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index fefd8cf42c35..d4fbb1356c4c 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -33,6 +33,9 @@
> #define KVM_ARM64_DEBUG_DIRTY_SHIFT 0
> #define KVM_ARM64_DEBUG_DIRTY (1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>
> +#define VCPU_WORKAROUND_2_FLAG_SHIFT 0
> +#define VCPU_WORKAROUND_2_FLAG (_AC(1, UL) << VCPU_WORKAROUND_2_FLAG_SHIFT)
> +
> /* Translate a kernel address of @sym into its equivalent linear mapping */
> #define kvm_ksym_ref(sym) \
> ({ \
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 469de8acd06f..9bef3f69bdcd 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -216,6 +216,9 @@ struct kvm_vcpu_arch {
> /* Exception Information */
> struct kvm_vcpu_fault_info fault;
>
> + /* State of various workarounds, see kvm_asm.h for bit assignment */
> + u64 workaround_flags;
> +
> /* Guest debug state */
> u64 debug_flags;
>
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 082110993647..eb7a5c2a2bfb 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -457,6 +457,30 @@ static inline int kvm_map_vectors(void)
> }
> #endif
>
> +#ifdef CONFIG_ARM64_SSBD
> +DECLARE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
> +
> +static inline int hyp_map_aux_data(void)
> +{
> + int cpu, err;
> +
> + for_each_possible_cpu(cpu) {
> + u64 *ptr;
> +
> + ptr = per_cpu_ptr(&arm64_ssbd_callback_required, cpu);
> + err = create_hyp_mappings(ptr, ptr + 1, PAGE_HYP);
> + if (err)
> + return err;
> + }
> + return 0;
> +}
> +#else
> +static inline int hyp_map_aux_data(void)
> +{
> + return 0;
> +}
> +#endif
> +
> #define kvm_phys_to_vttbr(addr) phys_to_ttbr(addr)
>
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index d9645236e474..c50cedc447f1 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -15,6 +15,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/arm-smccc.h>
> #include <linux/types.h>
> #include <linux/jump_label.h>
> #include <uapi/linux/psci.h>
> @@ -389,6 +390,39 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> return false;
> }
>
> +static inline bool __hyp_text __needs_ssbd_off(struct kvm_vcpu *vcpu)
> +{
> + if (!cpus_have_const_cap(ARM64_SSBD))
> + return false;
> +
> + return !(vcpu->arch.workaround_flags & VCPU_WORKAROUND_2_FLAG);
> +}
> +
> +static void __hyp_text __set_guest_arch_workaround_state(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ARM64_SSBD
> + /*
> + * The host runs with the workaround always present. If the
> + * guest wants it disabled, so be it...
> + */
> + if (__needs_ssbd_off(vcpu) &&
> + __hyp_this_cpu_read(arm64_ssbd_callback_required))
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2, 0, NULL);
> +#endif
> +}
> +
> +static void __hyp_text __set_host_arch_workaround_state(struct kvm_vcpu *vcpu)
> +{
> +#ifdef CONFIG_ARM64_SSBD
> + /*
> + * If the guest has disabled the workaround, bring it back on.
> + */
> + if (__needs_ssbd_off(vcpu) &&
> + __hyp_this_cpu_read(arm64_ssbd_callback_required))
> + arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_2, 1, NULL);
> +#endif
> +}
> +
> /* Switch to the guest for VHE systems running in EL2 */
> int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> {
> @@ -409,6 +443,8 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> sysreg_restore_guest_state_vhe(guest_ctxt);
> __debug_switch_to_guest(vcpu);
>
> + __set_guest_arch_workaround_state(vcpu);
> +
> do {
> /* Jump in the fire! */
> exit_code = __guest_enter(vcpu, host_ctxt);
> @@ -416,6 +452,8 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> /* And we're baaack! */
> } while (fixup_guest_exit(vcpu, &exit_code));
>
> + __set_host_arch_workaround_state(vcpu);
> +
> fp_enabled = fpsimd_enabled_vhe();
>
> sysreg_save_guest_state_vhe(guest_ctxt);
> @@ -465,6 +503,8 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> __sysreg_restore_state_nvhe(guest_ctxt);
> __debug_switch_to_guest(vcpu);
>
> + __set_guest_arch_workaround_state(vcpu);
> +
> do {
> /* Jump in the fire! */
> exit_code = __guest_enter(vcpu, host_ctxt);
> @@ -472,6 +512,8 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> /* And we're baaack! */
> } while (fixup_guest_exit(vcpu, &exit_code));
>
> + __set_host_arch_workaround_state(vcpu);
> +
> fp_enabled = __fpsimd_enabled_nvhe();
>
> __sysreg_save_state_nvhe(guest_ctxt);
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index a4c1b76240df..2d9b4795edb2 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -1490,6 +1490,10 @@ static int init_hyp_mode(void)
> }
> }
>
> + err = hyp_map_aux_data();
> + if (err)
> + kvm_err("Cannot map host auxilary data: %d\n", err);
> +
> return 0;
>
> out_err:
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
From: Yury Norov @ 2018-05-24 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523140620.GA27215@amd>
Hi Pavel,
On Wed, May 23, 2018 at 04:06:20PM +0200, Pavel Machek wrote:
> On Wed 2018-05-16 11:18:52, Yury Norov wrote:
> > Based on Andrew Pinski's patch-series.
> >
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
>
> So Andrew's signoff should be here?
Yes it should, but it lost since v4. I'll restore it.
> > ---
> > Documentation/arm64/ilp32.txt | 45 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> > create mode 100644 Documentation/arm64/ilp32.txt
> >
> > diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
> > new file mode 100644
> > index 000000000000..d0fd5109c4b2
> > --- /dev/null
> > +++ b/Documentation/arm64/ilp32.txt
> > @@ -0,0 +1,45 @@
> > +ILP32 AARCH64 SYSCALL ABI
> > +=========================
> > +
> > +This document describes the ILP32 syscall ABI and where it differs
> > +from the generic compat linux syscall interface.
>
> I was hoping to learn what ILP32 is / what is it good for, but no,
> this does not tell me... it would be good to do a short explanation
> here, and maybe reference it from cover letter of the series...
> Pavel
ILP32 is ABI acronym that means "Integers, Longs and Pointers are 32-bit".
And LP64 means "Longs and Pointers are 64-bit".
There's AN490 - "ILP32 for AArch64 Whitepaper" from ARM which covers
the topic:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html
And some talks:
http://connect.linaro.org/resource/bkk16/bkk16-305b/
Briefly, ILP32 is 32-bit ABI that works with AARCH64 instruction set. It looks
better in some performance tests, and is useful for compatibility with 32-bit
legacy code.
If you're more familiar with x86 terminology, in ARM world LP64 corresponds
to x86_64, AARCH32_EL0 corresponds to x86_32, and ILP32 corresponds to x32
ABI.
I'll add link to AN490 in next submission.
Yury
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 09/14] arm64: ssbd: Introduce thread flag to control userspace mitigation
From: Marc Zyngier @ 2018-05-24 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524120121.pjdw7qaybcsbf4fl@lakrids.cambridge.arm.com>
On 24/05/18 13:01, Mark Rutland wrote:
> On Tue, May 22, 2018 at 04:06:43PM +0100, Marc Zyngier wrote:
>> In order to allow userspace to be mitigated on demand, let's
>> introduce a new thread flag that prevents the mitigation from
>> being turned off when exiting to userspace, and doesn't turn
>> it on on entry into the kernel (with the assumtion that the
>
> Nit: s/assumtion/assumption/
>
>> mitigation is always enabled in the kernel itself).
>>
>> This will be used by a prctl interface introduced in a later
>> patch.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> On the assumption that this flag cannot be flipped while a task is in
> userspace:
Well, that's the case unless you get into the seccomp thing, which does
change TIF_SSBD on all threads of the task, without taking it to the
kernel first. That nicely breaks the state machine, and you end-up
running non-mitigated in the kernel. Oops.
I have a couple of patches fixing that, using a second flag
(TIF_SSBD_PENDING) that gets turned into the real thing on exit to
userspace. It's pretty ugly though.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Ulf Hansson @ 2018-05-24 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1687797a-93f1-7e5c-6060-01c12c070964@nvidia.com>
On 24 May 2018 at 11:36, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 24/05/18 08:04, Ulf Hansson wrote:
>
> ...
>
>>> Any reason why we could not add a 'boolean' argument to the API to
>>> indicate
>>> whether the new device should be linked? I think that I prefer the API
>>> handles it, but I can see there could be instances where drivers may wish
>>> to
>>> handle it themselves.
>>
>>
>> Coming back to this question. Both Tegra XUSB and Qcom Camera use
>> case, would benefit from doing the linking themselves, as it needs
>> different PM domains to be powered on depending on the current use
>> case - as to avoid wasting power.
>>
>> However, I can understand that you prefer some simplicity over
>> optimizations, as you told us. Then, does it mean that you are
>> insisting on extending the APIs with a boolean for linking, or are you
>> fine with the driver to call device_link_add()?
>
>
> I am fine with the driver calling device_link_add(), but I just wonder if we
> will find a several drivers doing this and then we will end up doing this
> later anyway.
Okay.
>
> The current API is called ...
>
> * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
> * @dev: Device to attach.
> * @index: The index of the PM domain.
>
> This naming and description is a bit misleading, because really it is not
> attaching the device that is passed, but creating a new device to attach a
> PM domain to. So we should consider renaming and changing the description
> and indicate that users need to link the device.
I picked the name to be consistent with the existing
genpd_dev_pm_attach(). Do you have a better suggestion?
I agree, some details is missing to the description, let me try to
improve it. Actually, I was trying to follow existing descriptions
from genpd_dev_pm_attach(), so perhaps that also needs a little
update.
However, do note that, neither genpd_dev_pm_attach() or
genpd_dev_pm_attach_by_id() is supposed to be called by drivers, but
rather only by the driver core. So description may not be so
important.
In regards to good descriptions, for sure the API added in patch9,
dev_pm_domain_attach_by_id(), needs a good one, as this is what
drivers should be using.
>
> Finally, how is a PM domain attached via calling genpd_dev_pm_attach_by_id()
> detached?
Via the existing genpd_dev_pm_detach(), according to what I have
described in the change log. I clarify the description in regards to
this as well.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Heiko Stuebner @ 2018-05-24 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <860b225a-94e0-c3cb-94c2-5e354e0ccb1f@t-chip.com.cn>
Hi Levin,
Am Donnerstag, 24. Mai 2018, 03:59:36 CEST schrieb Levin Du:
> Hi all, I'd like to quote reply of Robin Murphy at
> http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>
> >
> > I would suggest s/pin number/bit number in the associated GRF register/
> > here. At least in this RK3328 case there's only one pin, which isn't
> > numbered, and if you naively considered it pin 0 of this 'bank' you'd
> > already have the wrong number. Since we're dealing with the "random
> > SoC-specific controls" region of the GRF as opposed to the
> > relatively-consistent and organised pinmux parts, I don't think we
> > should rely on any assumptions about how things are laid out.
> >
> > I was initially going to suggest a more specific compatible string as
> > well, but on reflection I think the generic "rockchip,gpio-syscon" for
> > basic "flip this single GRF bit" functionality actually is the right way
> > to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
> > total related to this pin - the enable, value, and some pull controls
> > (which I assume apply when the output is disabled) - if at some point in
> > future we *did* want to start explicitly controlling the rest of them
> > too, then would be a good time to define a separate
> > "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
> > for that specialised functionality, independently of this basic one.
>
>
> Shall we go the generic "rockchip,gpio-syscon" way, or the specific
> "rockchip,rk3328-gpio-mute" way? I prefer the former one.
>
> The property of "gpio,syscon-dev" in gpio-syscon driver should be
> documented.
> Since the gpio controller is defined in the dtsi file, which inevitably
> contains voodoo
> register addresses. But at the board level dts file, there won't be more
> register
> addresses.
Past experience shows that the GRF is not really suitable for
generalization, as it's more of a dumping ground where chip designers
can put everything that's left over. This is especially true for
GRF_SOC_CONx registers, that really only contain pretty random bits.
So personally, I'd really prefer soc-specific compatibles as everywhere
else, instead of trying to push stuff into the devicetree that won't hold
up on future socs.
> On 2018-05-24 3:53 AM, Rob Herring wrote:
> > On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
> >> Hi Rob, Levin,
> >>
> >> sorry for being late to the party.
> >>
> >> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
> >>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
> >>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
> >>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
> >>>>>> From: Levin Du <djw@t-chip.com.cn>
> >>>>>>
> >>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> >>>>>> which do not belong to the general pinctrl.
> >>>>>>
> >>>>>> Adding gpio-syscon support makes controlling regulator or
> >>>>>> LED using these special pins very easy by reusing existing
> >>>>>> drivers, such as gpio-regulator and led-gpio.
> >>>>>>
> >>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> Changes in v2:
> >>>>>> - Rename gpio_syscon10 to gpio_mute in doc
> >>>>>>
> >>>>>> Changes in v1:
> >>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> >>>>>> - Add doc rockchip,gpio-syscon.txt
> >>>>>>
> >>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
> >>>>>>
> >>>>>> ++++++++++++++++++++++
> >>>>>>
> >>>>>> drivers/gpio/gpio-syscon.c | 30
> >>>>>>
> >>>>>> ++++++++++++++++
> >>>>>>
> >>>>>> 2 files changed, 71 insertions(+)
> >>>>>> create mode 100644
> >>>>>>
> >>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>>>>
> >>>>>> diff --git
> >>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..b1b2a67
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> >>>>>> @@ -0,0 +1,41 @@
> >>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
> >>>>>> +- gpio-controller: Marks the device node as a gpio controller.
> >>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
> >>>>>> + the second cell is used to specify the gpio polarity:
> >>>>>> + 0 = Active high,
> >>>>>> + 1 = Active low.
> >>>>> There's no need for this child node. Just make the parent node a gpio
> >>>>> controller.
> >>>>>
> >>>>> Rob
> >>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
> >>>> a
> >>>> gpio controller,
> >>>> like below?
> >>>>
> >>>> + grf: syscon at ff100000 {
> >>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
> >>>> "syscon", "simple-mfd";
> >>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
> >> I would disagree quite a bit here. The grf are the "general register files",
> >> a bunch of registers used for quite a lot of things, and so it seems
> >> among other users, also a gpio-controller for some more random pins
> >> not controlled through the regular gpio controllers.
> >>
> >> For a more fully stocked grf, please see
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
> >>
> >> So the gpio controller should definitly also be a subnode.
> > Sigh, yes, if there are a bunch of functions needing subnodes like the
> > above, then yes that makes sense. But that's not what has been
> > presented. Please make some attempt at defining *all* the functions.
> > An actual binding would be nice, but I'll settle for just a list of
> > things. The list should have functions that have DT dependencies (like
> > clocks for phys in the above) because until you do, you don't need
> > child nodes.
>
> In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
> various nodes,
> such as tsadc, cru, gmac2io, gmac2phy, and also pinctrl, which are not
> sub nodes of
> `grf`, but for reference only. The gpio-syscon node should also have
> similar behavior.
> They are not strongly coupled. The gpio-syscon node should be defined
> outside of the
> `grf` node.
Not necessarily.
I.e. things like the tsadc, cru etc have their own register space and only
some minor additional bits inside the GRF.
Other things like some phys and your mute-gpio are _fully embedded_ inside
the GRF and thus become child devices. This describes the hardware layout
way better, helps unclutter the devicetree and also shows this distinction
between "additional bits" and "embedded" clearly.
Heiko
^ permalink raw reply
* [PATCH 09/14] arm64: ssbd: Introduce thread flag to control userspace mitigation
From: Will Deacon @ 2018-05-24 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <833776ac-2b8c-b0f7-dcff-9c55afd67c65@arm.com>
On Thu, May 24, 2018 at 01:16:38PM +0100, Marc Zyngier wrote:
> On 24/05/18 13:01, Mark Rutland wrote:
> > On Tue, May 22, 2018 at 04:06:43PM +0100, Marc Zyngier wrote:
> >> In order to allow userspace to be mitigated on demand, let's
> >> introduce a new thread flag that prevents the mitigation from
> >> being turned off when exiting to userspace, and doesn't turn
> >> it on on entry into the kernel (with the assumtion that the
> >
> > Nit: s/assumtion/assumption/
> >
> >> mitigation is always enabled in the kernel itself).
> >>
> >> This will be used by a prctl interface introduced in a later
> >> patch.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >
> > On the assumption that this flag cannot be flipped while a task is in
> > userspace:
>
> Well, that's the case unless you get into the seccomp thing, which does
> change TIF_SSBD on all threads of the task, without taking it to the
> kernel first. That nicely breaks the state machine, and you end-up
> running non-mitigated in the kernel. Oops.
>
> I have a couple of patches fixing that, using a second flag
> (TIF_SSBD_PENDING) that gets turned into the real thing on exit to
> userspace. It's pretty ugly though.
... which introduces the need for atomics on the entry path too :(
I would /much/ rather kill the seccomp implicit enabling of the mitigation,
or at least have a way to opt-out per arch since it doesn't seem to be
technically justified imo.
Will
^ permalink raw reply
* [PATCH 13/14] arm64: KVM: Handle guest's ARCH_WORKAROUND_2 requests
From: Mark Rutland @ 2018-05-24 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-14-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:47PM +0100, Marc Zyngier wrote:
> In order to forward the guest's ARCH_WORKAROUND_2 calls to EL3,
> add a small(-ish) sequence to handle it at EL2. Special care must
> be taken to track the state of the guest itself by updating the
> workaround flags. We also rely on patching to enable calls into
> the firmware.
>
> Note that since we need to execute branches, this always executes
> after the Spectre-v2 mitigation has been applied.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kernel/asm-offsets.c | 1 +
> arch/arm64/kvm/hyp/hyp-entry.S | 38 +++++++++++++++++++++++++++++++++++++-
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 5bdda651bd05..323aeb5f2fe6 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -136,6 +136,7 @@ int main(void)
> #ifdef CONFIG_KVM_ARM_HOST
> DEFINE(VCPU_CONTEXT, offsetof(struct kvm_vcpu, arch.ctxt));
> DEFINE(VCPU_FAULT_DISR, offsetof(struct kvm_vcpu, arch.fault.disr_el1));
> + DEFINE(VCPU_WORKAROUND_FLAGS, offsetof(struct kvm_vcpu, arch.workaround_flags));
> DEFINE(CPU_GP_REGS, offsetof(struct kvm_cpu_context, gp_regs));
> DEFINE(CPU_USER_PT_REGS, offsetof(struct kvm_regs, regs));
> DEFINE(CPU_FP_REGS, offsetof(struct kvm_regs, fp_regs));
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index bffece27b5c1..5b1fa37ca1f4 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -106,8 +106,44 @@ el1_hvc_guest:
> */
> ldr x1, [sp] // Guest's x0
> eor w1, w1, #ARM_SMCCC_ARCH_WORKAROUND_1
> + cbz w1, wa_epilogue
> +
> + /* ARM_SMCCC_ARCH_WORKAROUND_2 handling */
> + eor w1, w1, #(ARM_SMCCC_ARCH_WORKAROUND_1 ^ \
> + ARM_SMCCC_ARCH_WORKAROUND_2)
... that took me a second. Lovely. :)
> cbnz w1, el1_trap
> - mov x0, x1
> +
> +#ifdef CONFIG_ARM64_SSBD
> +alternative_cb arm64_enable_wa2_handling
> + b wa2_end
> +alternative_cb_end
> + get_vcpu_ptr x2, x0
> + ldr x0, [x2, #VCPU_WORKAROUND_FLAGS]
> +
> + /* Sanitize the argument and update the guest flags*/
Nit: space before the trailing '*/'. Either that or use a '//' comment.
Otherwise, this looks fine, so with that fixed:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> + ldr x1, [sp, #8] // Guest's x1
> + clz w1, w1 // Murphy's device:
> + lsr w1, w1, #5 // w1 = !!w1 without using
> + eor w1, w1, #1 // the flags...
> + bfi x0, x1, #VCPU_WORKAROUND_2_FLAG_SHIFT, #1
> + str x0, [x2, #VCPU_WORKAROUND_FLAGS]
> +
> + /* Check that we actually need to perform the call */
> + hyp_ldr_this_cpu x0, arm64_ssbd_callback_required, x2
> + cbz x0, wa2_end
> +
> + mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2
> + smc #0
> +
> + /* Don't leak data from the SMC call */
> + mov x3, xzr
> +wa2_end:
> + mov x2, xzr
> + mov x1, xzr
> +#endif
> +
> +wa_epilogue:
> + mov x0, xzr
> add sp, sp, #16
> eret
>
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 10/14] arm64: ssbd: Add prctl interface for per-thread mitigation
From: Will Deacon @ 2018-05-24 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-11-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:44PM +0100, Marc Zyngier wrote:
> If running on a system that performs dynamic SSBD mitigation, allow
> userspace to request the mitigation for itself. This is implemented
> as a prctl call, allowing the mitigation to be enabled or disabled at
> will for this particular thread.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/ssbd.c | 107 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 108 insertions(+)
> create mode 100644 arch/arm64/kernel/ssbd.c
>
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index bf825f38d206..0025f8691046 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -54,6 +54,7 @@ arm64-obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
> arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
> arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> arm64-obj-$(CONFIG_ARM_SDE_INTERFACE) += sdei.o
> +arm64-obj-$(CONFIG_ARM64_SSBD) += ssbd.o
>
> obj-y += $(arm64-obj-y) vdso/ probes/
> obj-m += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/ssbd.c b/arch/arm64/kernel/ssbd.c
> new file mode 100644
> index 000000000000..34e3c430176b
> --- /dev/null
> +++ b/arch/arm64/kernel/ssbd.c
> @@ -0,0 +1,107 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 ARM Ltd, All Rights Reserved.
> + */
> +
> +#include <linux/sched.h>
> +#include <linux/thread_info.h>
> +
> +#include <asm/cpufeature.h>
> +
> +/*
> + * prctl interface for SSBD
> + * FIXME: Drop the below ifdefery once the common interface has been merged.
> + */
> +#ifdef PR_SPEC_STORE_BYPASS
> +static int ssbd_prctl_set(struct task_struct *task, unsigned long ctrl)
> +{
> + int state = arm64_get_ssbd_state();
> +
> + /* Unsupported or already mitigated */
> + if (state == ARM64_SSBD_UNKNOWN)
> + return -EINVAL;
> + if (state == ARM64_SSBD_MITIGATED)
> + return -EPERM;
I'm not sure this is the best thing to do. If the firmware says that the
CPU is mitigated, we should probably return 0 for PR_SPEC_DISABLE but
-EPERM for PR_SPEC_ENABLE (i.e. the part that doesn't work is disabling
the mitigation).
Will
^ permalink raw reply
* [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
From: Dr. Philipp Tomsich @ 2018-05-24 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524121524.GA3873@yury-thinkpad>
Yury & Pavel,
> On 24 May 2018, at 14:15, Yury Norov <ynorov@caviumnetworks.com> wrote:
>
> Hi Pavel,
>
> On Wed, May 23, 2018 at 04:06:20PM +0200, Pavel Machek wrote:
>> On Wed 2018-05-16 11:18:52, Yury Norov wrote:
>>> Based on Andrew Pinski's patch-series.
>>>
>>> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
>>
>> So Andrew's signoff should be here?
>
> Yes it should, but it lost since v4. I'll restore it.
>
>>> ---
>>> Documentation/arm64/ilp32.txt | 45 +++++++++++++++++++++++++++++++++++
>>> 1 file changed, 45 insertions(+)
>>> create mode 100644 Documentation/arm64/ilp32.txt
>>>
>>> diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
>>> new file mode 100644
>>> index 000000000000..d0fd5109c4b2
>>> --- /dev/null
>>> +++ b/Documentation/arm64/ilp32.txt
>>> @@ -0,0 +1,45 @@
>>> +ILP32 AARCH64 SYSCALL ABI
>>> +=========================
>>> +
>>> +This document describes the ILP32 syscall ABI and where it differs
>>> +from the generic compat linux syscall interface.
>>
>> I was hoping to learn what ILP32 is / what is it good for, but no,
>> this does not tell me... it would be good to do a short explanation
>> here, and maybe reference it from cover letter of the series...
>> Pavel
>
> ILP32 is ABI acronym that means "Integers, Longs and Pointers are 32-bit".
> And LP64 means "Longs and Pointers are 64-bit?.
Just a nitpick: ILP32 is in fact just the memory model, but calling from ILP32
code into the Linux kernel requires modifications to the syscall-ABI due to
datastructure layout changing (every time a pointer or a ?long? is present in
a structure). As such structures are passed between the userspace and the
kernel (and also due to the fact that time_t is an ?unsigned long? in the C
language standard), modifications to the syscall ABI in Linux are needed to
support ILP32 processes calling into the kernel.
Things get a bit more involved, as the final consensus was to pass 64bit
quantities in the lower half of 2 64bit registers instead of as a single register:
this makes the way (on AArch64) that an ILP32 process calls into the kernel
more dissimilar from a LP64 process calling the same syscall.
What this rambling boils down to is: ?ILP32" is the memory model, whereas
this series deals with the ?Linux/AArch64 syscall ABI for ILP32 processes?.
Thanks,
Phil.
>
> There's AN490 - "ILP32 for AArch64 Whitepaper" from ARM which covers
> the topic:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html
>
> And some talks:
> http://connect.linaro.org/resource/bkk16/bkk16-305b/
>
> Briefly, ILP32 is 32-bit ABI that works with AARCH64 instruction set. It looks
> better in some performance tests, and is useful for compatibility with 32-bit
> legacy code.
>
> If you're more familiar with x86 terminology, in ARM world LP64 corresponds
> to x86_64, AARCH32_EL0 corresponds to x86_32, and ILP32 corresponds to x32
> ABI.
>
> I'll add link to AN490 in next submission.
>
> Yury
>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 14/14] arm64: KVM: Add ARCH_WORKAROUND_2 discovery through ARCH_FEATURES_FUNC_ID
From: Mark Rutland @ 2018-05-24 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522150648.28297-15-marc.zyngier@arm.com>
On Tue, May 22, 2018 at 04:06:48PM +0100, Marc Zyngier wrote:
> Now that all our infrastructure is in place, let's expose the
> availability of ARCH_WORKAROUND_2 to guests. We take this opportunity
> to tidy up a couple of SMCCC constants.
>
> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm/include/asm/kvm_host.h | 12 ++++++++++++
> arch/arm64/include/asm/kvm_host.h | 23 +++++++++++++++++++++++
> arch/arm64/kvm/reset.c | 4 ++++
> virt/kvm/arm/psci.c | 18 ++++++++++++++++--
> 4 files changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index c7c28c885a19..d478766b56c1 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -315,6 +315,18 @@ static inline bool kvm_arm_harden_branch_predictor(void)
> return false;
> }
>
> +#define KVM_SSBD_UNKNOWN -1
> +#define KVM_SSBD_FORCE_DISABLE 0
> +#define KVM_SSBD_EL1_ENTRY 1
> +#define KVM_SSBD_FORCE_ENABLE 2
> +#define KVM_SSBD_MITIGATED 3
> +
> +static inline int kvm_arm_have_ssbd(void)
> +{
> + /* No way to detect it yet, pretend it is not there. */
> + return KVM_SSBD_UNKNOWN;
> +}
> +
> static inline void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu) {}
> static inline void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu) {}
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 9bef3f69bdcd..082b0dbb85c6 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -455,6 +455,29 @@ static inline bool kvm_arm_harden_branch_predictor(void)
> return cpus_have_const_cap(ARM64_HARDEN_BRANCH_PREDICTOR);
> }
>
> +#define KVM_SSBD_UNKNOWN -1
> +#define KVM_SSBD_FORCE_DISABLE 0
> +#define KVM_SSBD_EL1_ENTRY 1
> +#define KVM_SSBD_FORCE_ENABLE 2
> +#define KVM_SSBD_MITIGATED 3
> +
> +static inline int kvm_arm_have_ssbd(void)
> +{
> + switch (arm64_get_ssbd_state()) {
> + case ARM64_SSBD_FORCE_DISABLE:
> + return KVM_SSBD_FORCE_DISABLE;
> + case ARM64_SSBD_EL1_ENTRY:
> + return KVM_SSBD_EL1_ENTRY;
> + case ARM64_SSBD_FORCE_ENABLE:
> + return KVM_SSBD_FORCE_ENABLE;
> + case ARM64_SSBD_MITIGATED:
> + return KVM_SSBD_MITIGATED;
> + case ARM64_SSBD_UNKNOWN:
> + default:
> + return KVM_SSBD_UNKNOWN;
> + }
> +}
> +
> void kvm_vcpu_load_sysregs(struct kvm_vcpu *vcpu);
> void kvm_vcpu_put_sysregs(struct kvm_vcpu *vcpu);
>
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 3256b9228e75..20a7dfee8494 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -122,6 +122,10 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> /* Reset PMU */
> kvm_pmu_vcpu_reset(vcpu);
>
> + /* Default workaround setup is enabled (if supported) */
> + if (kvm_arm_have_ssbd() == KVM_SSBD_EL1_ENTRY)
> + vcpu->arch.workaround_flags |= VCPU_WORKAROUND_2_FLAG;
> +
> /* Reset timer */
> return kvm_timer_vcpu_reset(vcpu);
> }
> diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
> index c4762bef13c6..4843bfa1f986 100644
> --- a/virt/kvm/arm/psci.c
> +++ b/virt/kvm/arm/psci.c
> @@ -405,7 +405,7 @@ static int kvm_psci_call(struct kvm_vcpu *vcpu)
> int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> {
> u32 func_id = smccc_get_function(vcpu);
> - u32 val = PSCI_RET_NOT_SUPPORTED;
> + u32 val = SMCCC_RET_NOT_SUPPORTED;
> u32 feature;
>
> switch (func_id) {
> @@ -417,7 +417,21 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> switch(feature) {
> case ARM_SMCCC_ARCH_WORKAROUND_1:
> if (kvm_arm_harden_branch_predictor())
> - val = 0;
> + val = SMCCC_RET_SUCCESS;
> + break;
> + case ARM_SMCCC_ARCH_WORKAROUND_2:
> + switch (kvm_arm_have_ssbd()) {
> + case KVM_SSBD_FORCE_DISABLE:
> + case KVM_SSBD_UNKNOWN:
> + break;
> + case KVM_SSBD_EL1_ENTRY:
> + val = SMCCC_RET_SUCCESS;
> + break;
> + case KVM_SSBD_FORCE_ENABLE:
> + case KVM_SSBD_MITIGATED:
> + val = SMCCC_RET_NOT_REQUIRED;
> + break;
> + }
> break;
> }
> break;
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 09/14] ARM: spectre-v2: add PSCI based hardening
From: Russell King - ARM Linux @ 2018-05-24 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffeddbce-2cf7-c1d9-573b-dc4c38d1cbd7@arm.com>
On Thu, May 24, 2018 at 01:03:50PM +0100, Marc Zyngier wrote:
> On 23/05/18 20:45, Russell King - ARM Linux wrote:
> > On Tue, May 22, 2018 at 06:24:13PM +0100, Marc Zyngier wrote:
> >> On 21/05/18 12:45, Russell King wrote:
> >>> +#ifdef CONFIG_ARM_PSCI
> >>> + if (psci_ops.smccc_version != SMCCC_VERSION_1_0) {
> >>> + struct arm_smccc_res res;
> >>> +
> >>> + switch (psci_ops.conduit) {
> >>> + case PSCI_CONDUIT_HVC:
> >>> + arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> >>> + ARM_SMCCC_ARCH_WORKAROUND_1, &res);
> >>> + if ((int)res.a0 < 0)
> >>> + break;
> >>
> >> I just realised that there is a small, but significant difference
> >> between this and the arm64 version: On arm64, we have a table of
> >> vulnerable implementations, and we try the mitigation on a per-cpu
> >> basis. Here, you entirely rely on the firmware to discover whether the
> >> CPU needs mitigation or not. You then need to check for a return value
> >> of 1, which indicates that although the mitigation is implemented, it is
> >> not required on this particular CPU.
> >
> > Okay, so digging further into the documentation seems to suggest that we
> > only need to check the firmware for A72 and A57 CPUs, and given this
> > statement:
> >
> > "Arm recommends that the caller only call this on PEs for which a
> > firmware based mitigation of CVE-2017-5715 is required, or where
> > a local workaround is infeasible."
> >
> > it seems that the right answer is to ignore the PSCI based methods when
> > we have anything but these CPUs. Do you agree?
>
> For CPUs that are produced by ARM, I agree. I don't know about CPUs
> produced by ARM licensees though, so I'd rather use the opposite logic:
> Use the firmware unless the CPU is one of those that can be easily
> mitigated at EL1 (or isn't affected).
The "or isn't affected" is the difficult bit - I guess we could match
on the CPU vendor field though, and just reject all ARM CPUs that
aren't explicitly listed as having a problem.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v4] dt-bindings: mediatek: Add binding for mt2712 IOMMU and SMI
From: Yong Wu @ 2018-05-24 12:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds decriptions for mt2712 IOMMU and SMI.
In order to balance the bandwidth, mt2712 has two M4Us, two
smi-commons, 10 smi-larbs. and mt2712 is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt2712 M4U-SMI HW diagram is as below:
EMI
|
------------------------------------
| |
M4U0 M4U1
| |
smi-common0 smi-common1
| |
------------------------- --------------------------------
| | | | | | | | | |
| | | | | | | | | |
larb0 larb1 larb2 larb3 larb6 larb4 larb5 larb7 larb8 larb9
disp0 vdec cam venc jpg mdp1/disp1 mdp2/disp2 mdp3 vdo/nr tvd
All the connections are HW fixed, SW can NOT adjust it.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
---
change notes:
v4: change the license of the new file in this patch to SPDX.
v3: http://lists.infradead.org/pipermail/linux-mediatek/2018-May/013279.html
Add a new ECO port(DISP_RDMA2) in larb0/port7.
v2:
https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023848.html
v1:
https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023665.html
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 6 +-
.../memory-controllers/mediatek,smi-common.txt | 6 +-
.../memory-controllers/mediatek,smi-larb.txt | 5 +-
include/dt-bindings/memory/mt2712-larb-port.h | 95 ++++++++++++++++++++++
4 files changed, 106 insertions(+), 6 deletions(-)
create mode 100644 include/dt-bindings/memory/mt2712-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index 53c20ca..df5db73 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -40,6 +40,7 @@ video decode local arbiter, all these ports are according to the video HW.
Required properties:
- compatible : must be one of the following string:
"mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
+ "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW.
"mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
@@ -50,8 +51,9 @@ Required properties:
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
- dt-binding/memory/mt2701-larb-port.h for mt2701 and
- dt-binding/memory/mt8173-larb-port.h for mt8173
+ dt-binding/memory/mt2701-larb-port.h for mt2701,
+ dt-binding/memory/mt2712-larb-port.h for mt2712, and
+ dt-binding/memory/mt8173-larb-port.h for mt8173.
Example:
iommu: iommu at 10205000 {
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index aa614b2..615abdd 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -2,8 +2,9 @@ SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
-Mediatek SMI have two generations of HW architecture, mt8173 uses the second
-generation of SMI HW while mt2701 uses the first generation HW of SMI.
+Mediatek SMI have two generations of HW architecture, mt2712 and mt8173 use
+the second generation of SMI HW while mt2701 uses the first generation HW of
+SMI.
There's slight differences between the two SMI, for generation 2, the
register which control the iommu port is at each larb's register base. But
@@ -15,6 +16,7 @@ not needed for SMI generation 2.
Required properties:
- compatible : must be one of :
"mediatek,mt2701-smi-common"
+ "mediatek,mt2712-smi-common"
"mediatek,mt8173-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
index ddf46b8..083155c 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -4,8 +4,9 @@ The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
Required properties:
- compatible : must be one of :
- "mediatek,mt8173-smi-larb"
"mediatek,mt2701-smi-larb"
+ "mediatek,mt2712-smi-larb"
+ "mediatek,mt8173-smi-larb"
- reg : the register and size of this local arbiter.
- mediatek,smi : a phandle to the smi_common node.
- power-domains : a phandle to the power domain of this local arbiter.
@@ -15,7 +16,7 @@ Required properties:
the register.
- "smi" : It's the clock for transfer data and command.
-Required property for mt2701:
+Required property for mt2701 and mt2712:
- mediatek,larb-id :the hardware id of this larb.
Example:
diff --git a/include/dt-bindings/memory/mt2712-larb-port.h b/include/dt-bindings/memory/mt2712-larb-port.h
new file mode 100644
index 0000000..6f9aa73
--- /dev/null
+++ b/include/dt-bindings/memory/mt2712-larb-port.h
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef __DTS_IOMMU_PORT_MT2712_H
+#define __DTS_IOMMU_PORT_MT2712_H
+
+#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port))
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+#define M4U_LARB6_ID 6
+#define M4U_LARB7_ID 7
+#define M4U_LARB8_ID 8
+#define M4U_LARB9_ID 9
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0 MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_WDMA0 MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OD_R MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OD_W MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_MDP_RDMA0 MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_MDP_WDMA MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_DISP_RDMA2 MTK_M4U_ID(M4U_LARB0_ID, 7)
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_HW_VDEC_PP_EXT MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_HW_VDEC_UFO_EXT MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_HW_VDEC_VLD_EXT MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_HW_VDEC_VLD2_EXT MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_HW_VDEC_TILE MTK_M4U_ID(M4U_LARB1_ID, 9)
+#define M4U_PORT_HW_IMG_RESZ_EXT MTK_M4U_ID(M4U_LARB1_ID, 10)
+
+/* larb2 */
+#define M4U_PORT_CAM_DMA0 MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_CAM_DMA1 MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_CAM_DMA2 MTK_M4U_ID(M4U_LARB2_ID, 2)
+
+/* larb3 */
+#define M4U_PORT_VENC_RCPU MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_VENC_CUR_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_VENC_REF_CHROMA MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_VENC_CUR_LUMA MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_VENC_REF_LUMA MTK_M4U_ID(M4U_LARB3_ID, 8)
+
+/* larb4 */
+#define M4U_PORT_DISP_OVL1 MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_DISP_RDMA1 MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_DISP_WDMA1 MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_DISP_OD1_R MTK_M4U_ID(M4U_LARB4_ID, 3)
+#define M4U_PORT_DISP_OD1_W MTK_M4U_ID(M4U_LARB4_ID, 4)
+#define M4U_PORT_MDP_RDMA1 MTK_M4U_ID(M4U_LARB4_ID, 5)
+#define M4U_PORT_MDP_WROT1 MTK_M4U_ID(M4U_LARB4_ID, 6)
+
+/* larb5 */
+#define M4U_PORT_DISP_OVL2 MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_DISP_WDMA2 MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_MDP_RDMA2 MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_MDP_WROT0 MTK_M4U_ID(M4U_LARB5_ID, 3)
+
+/* larb6 */
+#define M4U_PORT_JPGDEC_WDMA_0 MTK_M4U_ID(M4U_LARB6_ID, 0)
+#define M4U_PORT_JPGDEC_WDMA_1 MTK_M4U_ID(M4U_LARB6_ID, 1)
+#define M4U_PORT_JPGDEC_BSDMA_0 MTK_M4U_ID(M4U_LARB6_ID, 2)
+#define M4U_PORT_JPGDEC_BSDMA_1 MTK_M4U_ID(M4U_LARB6_ID, 3)
+
+/* larb7 */
+#define M4U_PORT_MDP_RDMA3 MTK_M4U_ID(M4U_LARB7_ID, 0)
+#define M4U_PORT_MDP_WROT2 MTK_M4U_ID(M4U_LARB7_ID, 1)
+
+/* larb8 */
+#define M4U_PORT_VDO MTK_M4U_ID(M4U_LARB8_ID, 0)
+#define M4U_PORT_NR MTK_M4U_ID(M4U_LARB8_ID, 1)
+#define M4U_PORT_WR_CHANNEL0 MTK_M4U_ID(M4U_LARB8_ID, 2)
+
+/* larb9 */
+#define M4U_PORT_TVD MTK_M4U_ID(M4U_LARB9_ID, 0)
+#define M4U_PORT_WR_CHANNEL1 MTK_M4U_ID(M4U_LARB9_ID, 1)
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 09/14] arm64: ssbd: Introduce thread flag to control userspace mitigation
From: Marc Zyngier @ 2018-05-24 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524121944.GC8689@arm.com>
On 24/05/18 13:19, Will Deacon wrote:
> On Thu, May 24, 2018 at 01:16:38PM +0100, Marc Zyngier wrote:
>> On 24/05/18 13:01, Mark Rutland wrote:
>>> On Tue, May 22, 2018 at 04:06:43PM +0100, Marc Zyngier wrote:
>>>> In order to allow userspace to be mitigated on demand, let's
>>>> introduce a new thread flag that prevents the mitigation from
>>>> being turned off when exiting to userspace, and doesn't turn
>>>> it on on entry into the kernel (with the assumtion that the
>>>
>>> Nit: s/assumtion/assumption/
>>>
>>>> mitigation is always enabled in the kernel itself).
>>>>
>>>> This will be used by a prctl interface introduced in a later
>>>> patch.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>>
>>> On the assumption that this flag cannot be flipped while a task is in
>>> userspace:
>>
>> Well, that's the case unless you get into the seccomp thing, which does
>> change TIF_SSBD on all threads of the task, without taking it to the
>> kernel first. That nicely breaks the state machine, and you end-up
>> running non-mitigated in the kernel. Oops.
>>
>> I have a couple of patches fixing that, using a second flag
>> (TIF_SSBD_PENDING) that gets turned into the real thing on exit to
>> userspace. It's pretty ugly though.
>
> ... which introduces the need for atomics on the entry path too :(
Oh, I'm not saying it is nice. It would hit us on the exception return
to userspace for all tasks (and not only the mitigated ones). I'd rather
not have this at all.
> I would /much/ rather kill the seccomp implicit enabling of the mitigation,
> or at least have a way to opt-out per arch since it doesn't seem to be
> technically justified imo.
I agree. The semantics are really odd (the thread still runs unmitigated
until it traps into the kernel), and I don't really get why seccomp
tasks should get a special treatment compared to the rest of the userspace.
But 4.17 is only something like 10 days away, so whatever we decide,
we'd better decide it soon.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_fetch_*
From: Peter Zijlstra @ 2018-05-24 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527159586-8578-7-git-send-email-will.deacon@arm.com>
On Thu, May 24, 2018 at 11:59:43AM +0100, Will Deacon wrote:
> +static inline void set_bit(unsigned int nr, volatile unsigned long *p)
> {
> + p += BIT_WORD(nr);
> + atomic_long_fetch_or_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> }
>
> +static inline void clear_bit(unsigned int nr, volatile unsigned long *p)
> {
> + p += BIT_WORD(nr);
> + atomic_long_fetch_andnot_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> }
>
> +static inline void change_bit(unsigned int nr, volatile unsigned long *p)
> {
> + p += BIT_WORD(nr);
> + atomic_long_fetch_xor_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> }
Why use the fetch variants here?
^ permalink raw reply
* [PATCH 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_fetch_*
From: Will Deacon @ 2018-05-24 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524124410.GF12198@hirez.programming.kicks-ass.net>
On Thu, May 24, 2018 at 02:44:10PM +0200, Peter Zijlstra wrote:
> On Thu, May 24, 2018 at 11:59:43AM +0100, Will Deacon wrote:
> > +static inline void set_bit(unsigned int nr, volatile unsigned long *p)
> > {
> > + p += BIT_WORD(nr);
> > + atomic_long_fetch_or_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > }
> >
> > +static inline void clear_bit(unsigned int nr, volatile unsigned long *p)
> > {
> > + p += BIT_WORD(nr);
> > + atomic_long_fetch_andnot_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > }
> >
> > +static inline void change_bit(unsigned int nr, volatile unsigned long *p)
> > {
> > + p += BIT_WORD(nr);
> > + atomic_long_fetch_xor_relaxed(BIT_MASK(nr), (atomic_long_t *)p);
> > }
>
> Why use the fetch variants here?
I noticed the same thing just now; I'll drop that and just use the
non-value-returning variants. It's shame that I can't do the same for
the lock.h unlock code, but we don't have non-returning release variants.
Will
^ permalink raw reply
* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527097616-25214-3-git-send-email-Dave.Martin@arm.com>
On Wed, May 23, 2018 at 06:46:56PM +0100, Dave Martin wrote:
> Stateful CPU architecture extensions may require the signal frame
> to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
> However, changing this #define is an ABI break.
>
> To allow userspace the option of determining the signal frame size
> in a more forwards-compatible way, this patch adds a new auxv entry
> tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
> size that the process can observe during its lifetime.
>
> If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
> assume that the MINSIGSTKSZ #define is sufficient. This allows for
> a consistent interface with older kernels that do not provide
> AT_MINSIGSTKSZ.
>
> The idea is that libc could expose this via sysconf() or some
> similar mechanism.
>
> There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
> about userspace's own stack overheads and should not pretend to
> know.
[...]
> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index fac1c4d..9c18f0e 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -121,6 +121,9 @@
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/bug.h>
> +#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
> +
> typedef unsigned long elf_greg_t;
>
> #define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
> @@ -148,6 +151,14 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> do { \
> NEW_AUX_ENT(AT_SYSINFO_EHDR, \
> (elf_addr_t)current->mm->context.vdso); \
> + \
> + /* \
> + * Should always be nonzero unless there's a kernel bug. If \
> + * the we haven't determined a sensible value to give to \
"If the we"?
> + * userspace, omit the entry: \
> + */ \
> + if (likely(signal_minsigstksz)) \
> + NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
> } while (0)
>
> #define ARCH_HAS_SETUP_ADDITIONAL_PAGES
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 7675989..65ab83e 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -35,6 +35,8 @@
> #ifdef __KERNEL__
>
> #include <linux/build_bug.h>
> +#include <linux/cache.h>
> +#include <linux/init.h>
> #include <linux/stddef.h>
> #include <linux/string.h>
>
> @@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
> void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
> void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
>
> +extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
> +extern void __init minsigstksz_setup(void);
> +
> /* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
> #define SVE_SET_VL(arg) sve_set_current_vl(arg)
> #define SVE_GET_VL() sve_get_current_vl()
> diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
> index ec0a86d..743c0b8 100644
> --- a/arch/arm64/include/uapi/asm/auxvec.h
> +++ b/arch/arm64/include/uapi/asm/auxvec.h
> @@ -19,7 +19,8 @@
>
> /* vDSO location */
> #define AT_SYSINFO_EHDR 33
> +#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
Curious: but how do we avoid/detect conflicts at -rc1? I guess somebody just
needs to remember to run grep? (I know you have another series consolidating
the ID allocations).
> -#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
> +#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
>
> #endif
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9d1b06d..0e0b53d 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
> pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
>
> sve_setup();
> + minsigstksz_setup();
>
> /* Advertise that we have computed the system capabilities */
> set_sys_caps_initialised();
> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index 154b7d3..00b9990 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -17,6 +17,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/cache.h>
> #include <linux/compat.h>
> #include <linux/errno.h>
> #include <linux/kernel.h>
> @@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
> return 0;
> }
>
> -/* Determine the layout of optional records in the signal frame */
> -static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> +/*
> + * Determine the layout of optional records in the signal frame
> + *
> + * add_all: if true, lays out the biggest possible signal frame for
> + * this task; otherwise, generates a layout for the current state
> + * of the task.
> + */
> +static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
> + bool add_all)
> {
> int err;
>
> @@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return err;
>
> /* fault information, if valid */
> - if (current->thread.fault_code) {
> + if (add_all || current->thread.fault_code) {
> err = sigframe_alloc(user, &user->esr_offset,
> sizeof(struct esr_context));
> if (err)
> @@ -591,8 +599,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> if (system_supports_sve()) {
> unsigned int vq = 0;
>
> - if (test_thread_flag(TIF_SVE))
> - vq = sve_vq_from_vl(current->thread.sve_vl);
> + if (add_all || test_thread_flag(TIF_SVE)) {
> + int vl = sve_max_vl;
> +
> + if (!add_all)
> + vl = current->thread.sve_vl;
> +
> + vq = sve_vq_from_vl(vl);
> + }
>
> err = sigframe_alloc(user, &user->sve_offset,
> SVE_SIG_CONTEXT_SIZE(vq));
> @@ -603,7 +617,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
> return sigframe_alloc_end(user);
> }
>
> -
> static int setup_sigframe(struct rt_sigframe_user_layout *user,
> struct pt_regs *regs, sigset_t *set)
> {
> @@ -701,7 +714,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
> int err;
>
> init_user_layout(user);
> - err = setup_sigframe_layout(user);
> + err = setup_sigframe_layout(user, false);
> if (err)
> return err;
>
> @@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> thread_flags = READ_ONCE(current_thread_info()->flags);
> } while (thread_flags & _TIF_WORK_MASK);
> }
> +
> +unsigned long __ro_after_init signal_minsigstksz;
> +
> +/*
> + * Determine the stack space required for guaranteed signal devliery.
> + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> + * cpufeatures setup is assumed to be complete.
> + */
> +void __init minsigstksz_setup(void)
> +{
> + struct rt_sigframe_user_layout user;
> +
> + init_user_layout(&user);
> +
> + /*
> + * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
> + * be big enough, but it's our best guess:
> + */
> + if (WARN_ON(setup_sigframe_layout(&user, true)))
> + signal_minsigstksz = SIGFRAME_MAXSZ;
Can we not leave signal_minsigstksz as zero in this case?
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox