* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Arnd Bergmann @ 2016-11-25 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512445.DtnT51NQqg@amdc3058>
On Monday, October 31, 2016 7:24:46 PM CET Bartlomiej Zolnierkiewicz wrote:
> On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > I'd be fine with just getting a pull request with all the patches that
> > > > > had no negative feedback and that were not already applied (if any).
> > > >
> > > > Here it is (sorry for taking so long).
> > >
> > > I've just been digging in the dmesg logs from when I was using the
> > > Assabet+Neponset as my firewall, and it was having to use the IDE
> > > ide-cs driver rather than the pata pcmcia driver.
> > >
> > > I don't recall whether the pata pcmcia driver was a problem or not,
> > > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > > think PATA tries to use the "highest" possible access size by
> > > default...
> >
> > It doesn't actually - it defaults to 16-bits for PIO data access and
> > you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> > (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> > registers are accessed using 8-bits access by default transport
> > functions (which are used by pata_pcmcia).
>
> Please also note that:
>
> - assebet_defconfig currently doesn't even enable ide-cs
> (CONFIG_BLK_DEV_IDECS) in the mainline kernel
>
> - neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
> in the mainline kernel
>
> so there is no risk of breaking anything..
I noticed this older pull request in my todo folder, my interpretation
is that the concern was resolved and we simply missed it.
I've pulled it into next/defconfig for v4.10 now, with the above
in the merge commit text for reference.
Thanks,
Arnd
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Arnd Bergmann @ 2016-11-25 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87inrbqr16.fsf@belgarion.home>
On Friday, November 25, 2016 8:48:53 PM CET Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > The camera_supply_dummy_device definition is shared between a780 and a910,
> > but only provided when the first is enabled and fails to build for a
> > configuration with only a910:
> >
> > arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
> >
> > This moves the definition into its own section.
> >
> > Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Ah yes, I'll queue that up in pxa/fixes.
>
> This also means that you have a test robot which beats my Jenkins, as mine
> didn't complain. Do you have a specific defconfig or is it a randconfig which
> reveals that ?
>
It showed up in randconfig builds, two out of several hundred.
I'm not surprised that nobody else caught it.
Arnd
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Arnd Bergmann @ 2016-11-25 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017204919.GE3264@localhost>
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> >
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [ 0.097150] pgd = ffff000008602000
> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [ 0.097170] Modules linked in:
> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
>
> A Fixes: tag would be useful on a patch like this, to tell what patch
> introduced the problem. Please consider using them in the future.
>
> I've applied this one to fixes now.
Hi Olof,
I happened to still have this one in my todo folder as I must have
missed your reply, and I stumbled over it while looking for things
that may have gone missing.
I don't see it in v4.9-rc6, did it get dropped accidentally?
Arnd
^ permalink raw reply
* [GIT PULL] STi defconfig fix for v4.9-rcs
From: Arnd Bergmann @ 2016-11-25 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0492803d-d136-618d-bf06-51f0001d039b@st.com>
On Wednesday, November 23, 2016 9:59:14 AM CET Patrice Chotard wrote:
> STi defconfig fix:
>
> Enable HVA (Hardware Video Accelerator) video encoder
> driver for STMicroelectronics SoC.
Defconfig changes like this don't seem particularly urgent. Unless
there is a good reason, I'd suggest putting this into v4.10 instead.
Arnd
^ permalink raw reply
* [GIT PULL] STi DT fix for v4.9-rcs round 2
From: Arnd Bergmann @ 2016-11-25 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d109e729-0d50-40ac-ceeb-16d88a7a3e74@st.com>
On Wednesday, November 23, 2016 9:59:16 AM CET Patrice Chotard wrote:
> STi DT fix:
>
> The I2C nodes are missing #address-cells and #size-cells.
> This is causing warning at device tree compilation when
> some I2C device sub-nodes are defined.
>
>
Pulled into fixes branch, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.9, take 2
From: Arnd Bergmann @ 2016-11-25 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122143134.wxinkyp3x6jjnk7e@lukather>
On Tuesday, November 22, 2016 3:31:34 PM CET Maxime Ripard wrote:
> Allwinner fixes for 4.9, second iteration
>
> A renaming of the GR8 DTSI and DTS to make it explicitly part of the sun5i
> family.
>
Pulled into the fixe branch, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-25 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125152047.oadxi2xbgm4kdd7q@lukather>
On Fri, 25 Nov 2016 16:20:47 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> > On Thu, 24 Nov 2016 20:55:17 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > > others three only have 1.
> > > > Add the num-cs property to each node.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > >
> > > I don't think we have any code that uses it at the moment. What is the
> > > rationale behind this patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Hi Maxime,
> >
> > If num-cs isn't present nothing prevent to start a transfer with a
> > non-valid CS pin, resulting in an error.
> > num-cs are default property especially made for this and a SPI driver
> > should try to get the property at probe/attach time.
>
> Yes, but as far as I know, our driver doesn't. I'm all in for having
> support for that in our driver, but without it, that patch is kind of
> useless.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Yes the Linux driver doesn't use it but my upcoming one for FreeBSD
uses it. So it is not useless for downstream user of DTS.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-14-git-send-email-Dave.Martin@arm.com>
On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on
> it to be configured together with Scalable Vector Extension support
> in the same kernel, this patch implements basic support for
> saving/restoring the SVE state around kernel_neon_begin()...
> kernel_neon_end().
>
> This patch is not optimal and will generally save more state than
> necessary, more often than necessary. Further optimisations can be
> implemented in future patches.
>
> This patch is not intended to allow general-purpose _SVE_ code to
> execute in the kernel safely. That functionality may also follow
> in later patches.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
> arch/arm64/Kconfig | 1 -
> arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e8d04dd..7266761 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -880,7 +880,6 @@ endmenu
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> - depends on !KERNEL_MODE_NEON # until it works with SVE
> help
> The Scalable Vector Extension (SVE) is an extension to the AArch64
> execution state which complements and extends the SIMD functionality
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 81cfdb5..cb947dd 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> */
> void kernel_neon_begin_partial(u32 num_regs)
> {
> + preempt_disable();
> +
> + /*
> + * For now, we have no special storage for SVE registers in
> + * interrupt context, so always save the userland SVE state
> + * if there is any, even for interrupts.
> + */
> + if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
> + current->mm &&
> + !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
> + fpsimd_save_state(¤t->thread.fpsimd_state);
> + this_cpu_write(fpsimd_last_state, NULL);
> + }
> +
I am having trouble understanding why we need all of this if we don't
support SVE in the kernel. Could you elaborate?
> if (in_interrupt()) {
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> -
> BUG_ON(num_regs > 32);
> +
> + /* Save partial state for interrupted kernel-mode NEON code: */
> fpsimd_save_partial_state(s, roundup(num_regs, 2));
> } else {
> /*
> @@ -295,7 +310,6 @@ void kernel_neon_begin_partial(u32 num_regs)
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> if (current->mm &&
> !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> @@ -310,9 +324,9 @@ void kernel_neon_end(void)
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> }
> +
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 06/29] arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-7-git-send-email-Dave.Martin@arm.com>
On 25 November 2016 at 19:38, Dave Martin <Dave.Martin@arm.com> wrote:
> The EFI runtime services ABI permits calls to EFI to clobber
> certain FPSIMD/NEON registers, as per the AArch64 procedure call
> standard.
>
> Saving/restoring the clobbered registers around such calls needs
> KERNEL_MODE_NEON, but the dependency is missing from Kconfig.
>
> This patch adds the missing dependency.
>
> This will aid bisection of the patches implementing support for the
> ARM Scalable Vector Extension (SVE).
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..d008bb6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -963,6 +963,7 @@ config EFI_STUB
> config EFI
> bool "UEFI runtime support"
> depends on OF && !CPU_BIG_ENDIAN
> + depends on KERNEL_MODE_NEON
> select LIBFDT
> select UCS2_STRING
> select EFI_PARAMS_FROM_FDT
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Harald Welte @ 2016-11-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Hi Stefan,
On Thu, Nov 24, 2016 at 11:10:09PM +0100, Stefan Schmidt wrote:
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
I have no interest, motivtaion nor time to still work on ezx support. I
guess the number of people running a recent kernel on more than 10 year
old 2G-only phones is pretty low these days.
If anyone has a serious interest in taking this over, I think I still
have some A780 and A1200 units that I am happy to provide.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Robert Jarzmik @ 2016-11-25 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b97a129-bd10-b9be-616d-a3ea3b91b103@metafoo.de>
Lars-Peter Clausen <lars@metafoo.de> writes:
...
Ok Lars, let's do this : I integrate as many of your remarks as I can, and I
respin this serie, limited to patches 1, 2, 3, 4 and 5.
Then we'll iterate, that will enable me to settle the serie, as I was on
holidays and lost a bit my track. I'll send it hopefully next week once I've
gathered my thoughts.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata
From: Robert Jarzmik @ 2016-11-25 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123231320.fo3kilw5h7cctngc@earth>
Sebastian Reichel <sre@kernel.org> writes:
> Hi Robert,
>
> On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote:
>> As the power supply framework provides a way to store and retrieve
>> private supply data, use it.
>>
>> In the process, change the platform data for wm97xx_battery from a
>> container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>> drivers/input/touchscreen/wm97xx-core.c | 2 +-
>> drivers/power/supply/wm97xx_battery.c | 25 ++++++++++---------------
>> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> I queued this into power-supply's for-next branch.
Thanks Sebastian.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Robert Jarzmik @ 2016-11-25 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Stefan Schmidt <stefan@datenfreihafen.org> writes:
> Hello.
>
> On 24.11.2016 17:29, Arnd Bergmann wrote:
>> The camera_supply_dummy_device definition is shared between a780 and a910,
>> but only provided when the first is enabled and fails to build for a
>> configuration with only a910:
>>
>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>
>> This moves the definition into its own section.
>>
>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>
> I wonder what we should do with ezx.c.
>
> As far as I know neither Daniel nor Harald or myself are doing anything
> with this devices anymore. Besides a basic compile test having an ack or
> reviewed by from our side is a bit worthless. :/
>
> I should still have some of these phones around in a box somewhere. If
> there is someone with a good motivation and time to take over on this
> platform we will find a way to get the person this devices.
>
> Any takers? Robert? I guess you are already overloaded but you might
> also have an interest. Worth asking :)
Oh yes, I'm very interested in your box. Besides I really like old platforms
:)
> In the case nobody wants to pick up here what would you consider the
> bets way forward? I could send a patch removing ezx platform support
> from the kernel (basically ezx.c plus build support) or I can send a
> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
Unless another maintainer steps in, you can submit a patch to transfer the
maintainance onto me, and we'll see off mailing lists how we could arange the
boards transfer.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Robert Jarzmik @ 2016-11-25 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124162955.3887066-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The camera_supply_dummy_device definition is shared between a780 and a910,
> but only provided when the first is enabled and fails to build for a
> configuration with only a910:
>
> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>
> This moves the definition into its own section.
>
> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Ah yes, I'll queue that up in pxa/fixes.
This also means that you have a test robot which beats my Jenkins, as mine
didn't complain. Do you have a specific defconfig or is it a randconfig which
reveals that ?
Cheers.
--
Robert
^ permalink raw reply
* [RFC PATCH 29/29] arm64/sve: Limit vector length to 512 bits by default
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
As a transitional workaround for userspace incompatibilities caused
by enlargement of the signal frame, this patch adds a new config
option CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH, which default to n.
Unless this option is set to y, the vector length for SVE will be
limited to 512 bits. This leaves a bit of free space for other
architecture extensions just in case we need it.
This option will be removed and replaced with a user/kernel control
interface in the future.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/Kconfig | 35 +++++++++++++++++++++++++++++++++++
arch/arm64/mm/proc.S | 5 +++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index bf9915cb..7cd9812 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -887,6 +887,41 @@ config ARM64_SVE
To enable use of this extension on CPUs that implement it, say Y.
+if ARM64_SVE
+
+config ARM64_SVE_FULL_VECTOR_LENGTH
+ bool "Enable full hardware vector length for userspace"
+ default n
+ help
+ SVE vector lengths greater than 512 bits impact the size of signal
+ frames and therefore the size requirements for any userspace stack
+ onto which a signal may be delivered. Using larger vector lengths
+ may therefore cause problems for some software. For this reason, the
+ kernel currently limits the maximum vector length for userspace
+ software to 512 bits by default.
+
+ Enabling this option removes the limit, so that the full vector
+ length implemented by the hardware is made available to userspace.
+
+ Be aware: in general, software that (a) does not use SVE (including
+ via libraries), or (b) does not handle signals, or (c) uses default
+ process/thread stack sizes and does not use sigaltstack(2) should be
+ unaffected by enabling larger vectors. Software that does not meet
+ these criteria or that relies on certain legacy uses of the ucontext
+ API may be affected however.
+
+ This is a transitional compatibility option only and will be replaced
+ by a userspace ABI extension in the future. Do not assume that this
+ option will be available with compatible effect in future Linux
+ releases.
+
+ If you are developing software that uses SVE and understand the
+ implications, you can consider saying Y here.
+
+ If unsure, say N.
+
+endif
+
config ARM64_MODULE_CMODEL_LARGE
bool
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 1da8160..a2839e6 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -198,6 +198,11 @@ ENTRY(__cpu_setup)
mrs_s x5, ZIDR_EL1 // SVE: Enable full vector len
and x5, x5, #ZCR_EL1_LEN_MASK // initially
+#ifndef CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH
+ mov x6, #(512 / 128 - 1) // Clamp VL to 512 bits
+ cmp x5, x6
+ csel x5, x5, x6, lo
+#endif
msr_s ZCR_EL1, x5
b 2f
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 28/29] arm64: KVM: Treat SVE use by guests as undefined instruction execution
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
We don't currently support context-switching of Scalable Vector
Extension context between vcpus, and the SVE access exception is
thus left masked by default at EL2 when running a vcpu.
However, there's nothing to stop a guest trying to use SVE. If it
does, we'll get an SVE access exception to EL2 which will cause KVM
to panic since this exception isn't yet recognised.
This patch adds knowledge to KVM about the SVE access exception,
translating it into an undefined instruction exception injected to
the vcpu.
This prevents a malicious guest from panicking the host by
attempted SVE use.
SVE-enabled guests will still not work properly for now, but they
won't take the host down.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kvm/handle_exit.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index a204adf..f43b6d0 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -125,6 +125,14 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
return ret;
}
+static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ /* Until SVE is supported for guests: */
+ kvm_inject_undefined(vcpu);
+
+ return 1;
+}
+
static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_WFx] = kvm_handle_wfx,
[ESR_ELx_EC_CP15_32] = kvm_handle_cp15_32,
@@ -137,6 +145,7 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_HVC64] = handle_hvc,
[ESR_ELx_EC_SMC64] = handle_smc,
[ESR_ELx_EC_SYS64] = kvm_handle_sys_reg,
+ [ESR_ELx_EC_SVE] = handle_sve,
[ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 27/29] arm64/sve: ptrace support
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
From: Alan Hayward <alan.hayward@arm.com>
This patch adds support for accessing a task's SVE registers via
ptrace.
Some additional helpers are added in order to support the SVE/
FPSIMD register view synchronisation operations that are required
in order to make the NT_PRFPREG and NT_ARM_SVE regsets interact
correctly.
fpr_set()/fpr_get() are refactored into backend/frontend functions,
so that the core can be reused by sve_set()/sve_get() for the case
where no SVE registers are stored for a thread.
Signed-off-by: Alan Hayward <alan.hayward@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/fpsimd.h | 20 +++
arch/arm64/include/uapi/asm/ptrace.h | 125 +++++++++++++++
arch/arm64/include/uapi/asm/sigcontext.h | 4 +
arch/arm64/kernel/fpsimd.c | 42 +++++
arch/arm64/kernel/ptrace.c | 254 ++++++++++++++++++++++++++++++-
include/uapi/linux/elf.h | 1 +
6 files changed, 440 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index e39066a..88bcf69 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -35,6 +35,10 @@ struct fpsimd_state {
__uint128_t vregs[32];
u32 fpsr;
u32 fpcr;
+ /*
+ * For ptrace compatibility, pad to next 128-bit
+ * boundary here if extending this struct.
+ */
};
};
/* the id of the last cpu to have restored this state */
@@ -98,6 +102,22 @@ extern void sve_save_state(void *state, u32 *pfpsr);
extern void sve_load_state(void const *state, u32 const *pfpsr);
extern unsigned int sve_get_vl(void);
+/*
+ * FPSIMD/SVE synchronisation helpers for ptrace:
+ * For use on stopped tasks only
+ */
+
+extern void fpsimd_sync_to_sve(struct task_struct *task);
+
+#ifdef CONFIG_ARM64_SVE
+extern void fpsimd_sync_to_fpsimd(struct task_struct *task);
+extern void fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task);
+#else /* !CONFIG_ARM64_SVE */
+static void __maybe_unused fpsimd_sync_to_fpsimd(struct task_struct *task) { }
+static void __maybe_unused fpsimd_sync_from_fpsimd_zeropad(
+ struct task_struct *task) { }
+#endif /* !CONFIG_ARM64_SVE */
+
#endif
#endif
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index b5c3933..48b57a0 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -22,6 +22,7 @@
#include <linux/types.h>
#include <asm/hwcap.h>
+#include <asm/sigcontext.h>
/*
@@ -77,6 +78,7 @@ struct user_fpsimd_state {
__uint128_t vregs[32];
__u32 fpsr;
__u32 fpcr;
+ /* Pad to next 128-bit boundary here if extending this struct */
};
struct user_hwdebug_state {
@@ -89,6 +91,129 @@ struct user_hwdebug_state {
} dbg_regs[16];
};
+/* SVE/FP/SIMD state (NT_ARM_SVE) */
+
+struct user_sve_header {
+ __u32 size; /* total meaningful regset content in bytes */
+ __u32 max_size; /* maxmium possible size for this thread */
+ __u16 vl; /* current vector length */
+ __u16 max_vl; /* maximum possible vector length */
+ __u16 flags;
+ __u16 __reserved;
+};
+
+/* Definitions for user_sve_header.flags: */
+#define SVE_PT_REGS_MASK (1 << 0)
+
+#define SVE_PT_REGS_FPSIMD 0
+#define SVE_PT_REGS_SVE SVE_PT_REGS_MASK
+
+
+/*
+ * The remainder of the SVE state follows struct user_sve_header. The
+ * total size of the SVE state (including header) depends on the
+ * metadata in the header: SVE_PT_SIZE(vq, flags) gives the total size
+ * of the state in bytes, including the header.
+ *
+ * Refer to <asm/sigcontext.h> for details of how to pass the correct
+ * "vq" argument to these macros.
+ */
+
+/* Offset from the start of struct user_sve_header to the register data */
+#define SVE_PT_REGS_OFFSET ((sizeof(struct sve_context) + 15) / 16 * 16)
+
+/*
+ * The register data content and layout depends on the value of the
+ * flags field.
+ */
+
+/*
+ * (flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD case:
+ *
+ * The payload starts at offset SVE_PT_FPSIMD_OFFSET, and is of type
+ * struct user_fpsimd_state. Additional data might be appended in the
+ * future: use SVE_PT_FPSIMD_SIZE(vq, flags) to compute the total size.
+ * SVE_PT_FPSIMD_SIZE(vq, flags) will never be less than
+ * sizeof(struct user_fpsimd_state).
+ */
+
+#define SVE_PT_FPSIMD_OFFSET SVE_PT_REGS_OFFSET
+
+#define SVE_PT_FPSIMD_SIZE(vq, flags) (sizeof(struct user_fpsimd_state))
+
+/*
+ * (flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE case:
+ *
+ * The payload starts at offset SVE_PT_SVE_OFFSET, and is of size
+ * SVE_PT_SVE_SIZE(vq, flags).
+ *
+ * Additional macros describe the contents and layout of the payload.
+ * For each, SVE_PT_SVE_x_OFFSET(args) is the start offset relative to
+ * the start of struct user_sve_header, and SVE_PT_SVE_x_SIZE(args) is
+ * the size in bytes:
+ *
+ * x type description
+ * - ---- -----------
+ * ZREGS \
+ * ZREG |
+ * PREGS | refer to <asm/sigcontext.h>
+ * PREG |
+ * FFR /
+ *
+ * FPSR uint32_t FPSR
+ * FPCR uint32_t FPCR
+ *
+ * Additional data might be appended in the future.
+ */
+
+#define SVE_PT_SVE_ZREG_SIZE(vq) SVE_SIG_ZREG_SIZE(vq)
+#define SVE_PT_SVE_PREG_SIZE(vq) SVE_SIG_PREG_SIZE(vq)
+#define SVE_PT_SVE_FFR_SIZE(vq) SVE_SIG_FFR_SIZE(vq)
+#define SVE_PT_SVE_FPSR_SIZE sizeof(__u32)
+#define SVE_PT_SVE_FPCR_SIZE sizeof(__u32)
+
+#define __SVE_SIG_TO_PT(offset) \
+ ((offset) - SVE_SIG_REGS_OFFSET + SVE_PT_REGS_OFFSET)
+
+#define SVE_PT_SVE_OFFSET SVE_PT_REGS_OFFSET
+
+#define SVE_PT_SVE_ZREGS_OFFSET \
+ __SVE_SIG_TO_PT(SVE_SIG_ZREGS_OFFSET)
+#define SVE_PT_SVE_ZREG_OFFSET(vq, n) \
+ __SVE_SIG_TO_PT(SVE_SIG_ZREG_OFFSET(vq, n))
+#define SVE_PT_SVE_ZREGS_SIZE(vq) \
+ (SVE_PT_SVE_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_PT_SVE_ZREGS_OFFSET)
+
+#define SVE_PT_SVE_PREGS_OFFSET(vq) \
+ __SVE_SIG_TO_PT(SVE_SIG_PREGS_OFFSET(vq))
+#define SVE_PT_SVE_PREG_OFFSET(vq, n) \
+ __SVE_SIG_TO_PT(SVE_SIG_PREG_OFFSET(vq, n))
+#define SVE_PT_SVE_PREGS_SIZE(vq) \
+ (SVE_PT_SVE_PREG_OFFSET(vq, SVE_NUM_PREGS) - \
+ SVE_PT_SVE_PREGS_OFFSET(vq))
+
+#define SVE_PT_SVE_FFR_OFFSET(vq) \
+ __SVE_SIG_TO_PT(SVE_SIG_FFR_OFFSET(vq))
+
+#define SVE_PT_SVE_FPSR_OFFSET(vq) \
+ ((SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq) + 15) / 16 * 16)
+#define SVE_PT_SVE_FPCR_OFFSET(vq) \
+ (SVE_PT_SVE_FPSR_OFFSET(vq) + SVE_PT_SVE_FPSR_SIZE)
+
+/*
+ * Any future extension appended after FPCR must be aligned to the next
+ * 128-bit boundary.
+ */
+
+#define SVE_PT_SVE_SIZE(vq, flags) \
+ ((SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE - \
+ SVE_PT_SVE_OFFSET + 15) / 16 * 16)
+
+#define SVE_PT_SIZE(vq, flags) \
+ (((flags) & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE ? \
+ SVE_PT_SVE_OFFSET + SVE_PT_SVE_SIZE(vq, flags) \
+ : SVE_PT_FPSIMD_OFFSET + SVE_PT_FPSIMD_SIZE(vq, flags))
+
#endif /* __ASSEMBLY__ */
#endif /* _UAPI__ASM_PTRACE_H */
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index 11c915d..91e55de 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -16,6 +16,8 @@
#ifndef _UAPI__ASM_SIGCONTEXT_H
#define _UAPI__ASM_SIGCONTEXT_H
+#ifndef __ASSEMBLY__
+
#include <linux/types.h>
/*
@@ -96,6 +98,8 @@ struct sve_context {
__u16 __reserved[3];
};
+#endif /* !__ASSEMBLY__ */
+
/*
* The SVE architecture leaves space for future expansion of the
* vector length beyond its initial architectural limit of 2048 bits
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 1750301..6a5e725 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -417,6 +417,48 @@ void fpsimd_flush_task_state(struct task_struct *t)
t->thread.fpsimd_state.cpu = NR_CPUS;
}
+#ifdef CONFIG_ARM64_SVE
+
+/* FPSIMD/SVE synchronisation helpers for ptrace */
+
+void fpsimd_sync_to_sve(struct task_struct *task)
+{
+ if (!test_tsk_thread_flag(task, TIF_SVE))
+ task_fpsimd_to_sve(task);
+}
+
+void fpsimd_sync_to_fpsimd(struct task_struct *task)
+{
+ if (test_tsk_thread_flag(task, TIF_SVE))
+ task_sve_to_fpsimd(task);
+}
+
+static void __fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task,
+ unsigned int vq)
+{
+ struct sve_struct fpsimd_sve_state(vq) *sst =
+ __task_sve_state(task);
+ struct fpsimd_state *fst = &task->thread.fpsimd_state;
+ unsigned int i;
+
+ if (!test_tsk_thread_flag(task, TIF_SVE))
+ return;
+
+ memset(sst->zregs, 0, sizeof(sst->zregs));
+
+ for (i = 0; i < 32; ++i)
+ sst->zregs[i][0] = fst->vregs[i];
+}
+
+void fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task)
+{
+ unsigned int vl = sve_get_vl();
+
+ __fpsimd_sync_from_fpsimd_zeropad(task, sve_vq_from_vl(vl));
+}
+
+#endif /* CONFIG_ARM64_SVE */
+
#ifdef CONFIG_KERNEL_MODE_NEON
static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index e0c81da..bdd2ad3 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -30,7 +30,9 @@
#include <linux/seccomp.h>
#include <linux/security.h>
#include <linux/init.h>
+#include <linux/sched.h>
#include <linux/signal.h>
+#include <linux/string.h>
#include <linux/uaccess.h>
#include <linux/perf_event.h>
#include <linux/hw_breakpoint.h>
@@ -611,13 +613,46 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
/*
* TODO: update fp accessors for lazy context switching (sync/flush hwstate)
*/
+static int __fpr_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf, unsigned int start_pos)
+{
+ struct user_fpsimd_state *uregs;
+
+ fpsimd_sync_to_fpsimd(target);
+
+ uregs = &target->thread.fpsimd_state.user_fpsimd;
+ return user_regset_copyout(&pos, &count, &kbuf, &ubuf, uregs,
+ start_pos, start_pos + sizeof(*uregs));
+}
+
static int fpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
- struct user_fpsimd_state *uregs;
- uregs = &target->thread.fpsimd_state.user_fpsimd;
- return user_regset_copyout(&pos, &count, &kbuf, &ubuf, uregs, 0, -1);
+ return __fpr_get(target, regset, pos, count, kbuf, ubuf, 0);
+}
+
+static int __fpr_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf,
+ unsigned int start_pos)
+{
+ int ret;
+ struct user_fpsimd_state newstate;
+
+ fpsimd_sync_to_fpsimd(target);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newstate,
+ start_pos, start_pos + sizeof(newstate));
+ if (ret)
+ return ret;
+
+ target->thread.fpsimd_state.user_fpsimd = newstate;
+
+ return ret;
}
static int fpr_set(struct task_struct *target, const struct user_regset *regset,
@@ -625,14 +660,14 @@ static int fpr_set(struct task_struct *target, const struct user_regset *regset,
const void *kbuf, const void __user *ubuf)
{
int ret;
- struct user_fpsimd_state newstate;
- ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &newstate, 0, -1);
+ ret = __fpr_set(target, regset, pos, count, kbuf, ubuf, 0);
if (ret)
return ret;
- target->thread.fpsimd_state.user_fpsimd = newstate;
+ fpsimd_sync_from_fpsimd_zeropad(target);
fpsimd_flush_task_state(target);
+
return ret;
}
@@ -685,6 +720,204 @@ static int system_call_set(struct task_struct *target,
return ret;
}
+#ifdef CONFIG_ARM64_SVE
+
+static int sve_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ int ret;
+ struct user_sve_header header;
+ unsigned int vq;
+ unsigned long start, end;
+
+ /* Header */
+ memset(&header, 0, sizeof(header));
+
+ header.vl = sve_get_vl();
+
+ BUG_ON(!sve_vl_valid(header.vl));
+ vq = sve_vq_from_vl(header.vl);
+
+ /* Until runtime or per-task vector length changing is supported: */
+ header.max_vl = header.vl;
+
+ header.flags = test_tsk_thread_flag(target, TIF_SVE) ?
+ SVE_PT_REGS_SVE : SVE_PT_REGS_FPSIMD;
+
+ header.size = SVE_PT_SIZE(vq, header.flags);
+ header.max_size = SVE_PT_SIZE(vq, SVE_PT_REGS_SVE);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &header,
+ 0, sizeof(header));
+ if (ret)
+ return ret;
+
+ /* Registers: FPSIMD-only case */
+
+ BUILD_BUG_ON(SVE_PT_FPSIMD_OFFSET != sizeof(header));
+
+ if ((header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD)
+ return __fpr_get(target, regset, pos, count, kbuf, ubuf,
+ SVE_PT_FPSIMD_OFFSET);
+
+ /* Otherwise: full SVE case */
+
+ BUILD_BUG_ON(SVE_PT_SVE_OFFSET != sizeof(header));
+
+ start = SVE_PT_SVE_OFFSET;
+ end = SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq);
+
+ BUG_ON((char *)__task_sve_state(target) < (char *)target);
+ BUG_ON(end < start);
+ BUG_ON(arch_task_struct_size < end - start);
+ BUG_ON((char *)__task_sve_state(target) - (char *)target >
+ arch_task_struct_size - (end - start));
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ __task_sve_state(target),
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = SVE_PT_SVE_FPSR_OFFSET(vq);
+
+ BUG_ON(end < start);
+ ret = user_regset_copyout_zero(&pos, &count, &kbuf, &ubuf,
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE;
+
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) <
+ (char *)&target->thread.fpsimd_state.fpsr);
+ BUG_ON(end < start);
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) -
+ (char *)&target->thread.fpsimd_state.fpsr !=
+ end - start);
+
+ ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpsimd_state.fpsr,
+ start, end);
+ if (ret)
+ return ret;
+
+ start = end;
+ end = (SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE) + 15) / 16 * 16;
+ BUG_ON(end < start);
+
+ return user_regset_copyout_zero(&pos, &count, &kbuf, &ubuf,
+ start, end);
+}
+
+static int sve_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ int ret;
+ struct user_sve_header header;
+ unsigned int vq;
+ unsigned long start, end;
+
+ /* Header */
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &header,
+ 0, sizeof(header));
+ if (ret)
+ goto out;
+
+ if (header.vl != sve_get_vl())
+ return -EINVAL;
+
+ BUG_ON(!sve_vl_valid(header.vl));
+ vq = sve_vq_from_vl(header.vl);
+
+ if (header.flags & ~SVE_PT_REGS_MASK)
+ return -EINVAL;
+
+ /* Registers: FPSIMD-only case */
+
+ BUILD_BUG_ON(SVE_PT_FPSIMD_OFFSET != sizeof(header));
+
+ if ((header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD) {
+ ret = __fpr_set(target, regset, pos, count, kbuf, ubuf,
+ SVE_PT_FPSIMD_OFFSET);
+ clear_tsk_thread_flag(target, TIF_SVE);
+ goto out;
+ }
+
+ /* Otherwise: full SVE case */
+
+ fpsimd_sync_to_sve(target);
+ set_tsk_thread_flag(target, TIF_SVE);
+
+ BUILD_BUG_ON(SVE_PT_SVE_OFFSET != sizeof(header));
+
+ start = SVE_PT_SVE_OFFSET;
+ end = SVE_PT_SVE_FFR_OFFSET(vq) + SVE_PT_SVE_FFR_SIZE(vq);
+
+ BUG_ON((char *)__task_sve_state(target) < (char *)target);
+ BUG_ON(end < start);
+ BUG_ON(arch_task_struct_size < end - start);
+ BUG_ON((char *)__task_sve_state(target) - (char *)target >
+ arch_task_struct_size - (end - start));
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ __task_sve_state(target),
+ start, end);
+ if (ret)
+ goto out;
+
+ start = end;
+ end = SVE_PT_SVE_FPSR_OFFSET(vq);
+
+ BUG_ON(end < start);
+ ret = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
+ start, end);
+ if (ret)
+ goto out;
+
+ start = end;
+ end = SVE_PT_SVE_FPCR_OFFSET(vq) + SVE_PT_SVE_FPCR_SIZE;
+
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) <
+ (char *)&target->thread.fpsimd_state.fpsr);
+ BUG_ON(end < start);
+ BUG_ON((char *)(&target->thread.fpsimd_state.fpcr + 1) -
+ (char *)&target->thread.fpsimd_state.fpsr !=
+ end - start);
+
+ ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+ &target->thread.fpsimd_state.fpsr,
+ start, end);
+
+out:
+ fpsimd_flush_task_state(target);
+ return ret;
+}
+
+#else /* !CONFIG_ARM64_SVE */
+
+static int sve_get(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ void *kbuf, void __user *ubuf)
+{
+ return -EINVAL;
+}
+
+static int sve_set(struct task_struct *target,
+ const struct user_regset *regset,
+ unsigned int pos, unsigned int count,
+ const void *kbuf, const void __user *ubuf)
+{
+ return -EINVAL;
+}
+
+#endif /* !CONFIG_ARM64_SVE */
+
enum aarch64_regset {
REGSET_GPR,
REGSET_FPR,
@@ -694,6 +927,7 @@ enum aarch64_regset {
REGSET_HW_WATCH,
#endif
REGSET_SYSTEM_CALL,
+ REGSET_SVE,
};
static const struct user_regset aarch64_regsets[] = {
@@ -751,6 +985,14 @@ static const struct user_regset aarch64_regsets[] = {
.get = system_call_get,
.set = system_call_set,
},
+ [REGSET_SVE] = { /* Scalable Vector Extension */
+ .core_note_type = NT_ARM_SVE,
+ .n = (SVE_PT_SIZE(SVE_VQ_MAX, SVE_PT_REGS_SVE) + 15) / 16,
+ .size = 16,
+ .align = 16,
+ .get = sve_get,
+ .set = sve_set,
+ },
};
static const struct user_regset_view user_aarch64_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index b59ee07..23c6585 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -414,6 +414,7 @@ typedef struct elf64_shdr {
#define NT_ARM_HW_BREAK 0x402 /* ARM hardware breakpoint registers */
#define NT_ARM_HW_WATCH 0x403 /* ARM hardware watchpoint registers */
#define NT_ARM_SYSTEM_CALL 0x404 /* ARM system call number */
+#define NT_ARM_SVE 0x405 /* ARM Scalable Vector Extension registers */
#define NT_METAG_CBUF 0x500 /* Metag catch buffer registers */
#define NT_METAG_RPIPE 0x501 /* Metag read pipeline state */
#define NT_METAG_TLS 0x502 /* Metag TLS pointer */
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 26/29] arm64/sve: Avoid stale user register state after SVE access exception
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Currently, when an SVE access exception is taken from userspace,
the FPSIMD state in the task_struct is converted to SVE state and
reloaded as SVE state.
Unfortunately, since we've been executing in userspace there's no
guarantee that the FPSIMD state saved will actually be up to date
with respect to the registers, so updates may be lost.
This patch saves the FPSIMD state back to the task_struct first, to
ensure that the task_struct copy of the data is up to date.
Also, the CPACR handling logic is removed since task_fpsimd_load()
handles it anyway.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 2e1056e..1750301 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -103,22 +103,18 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
static void task_fpsimd_to_sve(struct task_struct *task);
static void task_fpsimd_load(struct task_struct *task);
+static void task_fpsimd_save(struct task_struct *task);
void do_sve_acc(unsigned int esr, struct pt_regs *regs)
{
- if (test_and_set_thread_flag(TIF_SVE)) {
- unsigned long tmp;
-
- asm ("mrs %0, cpacr_el1" : "=r" (tmp));
-
- printk(KERN_INFO "%s: Strange, ZEN=%u\n",
- __func__, (unsigned int)((tmp >> 16) & 3));
- BUG();
- }
-
BUG_ON(is_compat_task());
+ task_fpsimd_save(current);
+
task_fpsimd_to_sve(current);
+ if (test_and_set_thread_flag(TIF_SVE))
+ BUG(); /* We shouldn't trap if SVE was already enabled! */
+
task_fpsimd_load(current);
}
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 25/29] arm64/sve: Avoid preempt_disable() during sigreturn
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Currently the sigreturn implementation for SVE relies on
preempt_disable() to avoid an intervening context switch from
corrupting the SVE state in the task_struct.
Unforunately, __get_user() and friends are not safe under
preempt_disable().
As an alternative, this patch removes preempt_disable() and sets
TIF_FOREIGN_FPSTATE instead: this will inform the context switch
code that the current CPU registers don't contain the SVE/FPSIMD
state of the current task, preventing writeback to the task_struct
during context switch.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/signal.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 2528ec1..942d66f 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -256,10 +256,8 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
if (vl != sve_get_vl())
return -EINVAL;
- preempt_disable();
-
set_thread_flag(TIF_FOREIGN_FPSTATE);
- set_thread_flag(TIF_SVE);
+ barrier();
BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
@@ -270,7 +268,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
SVE_SIG_REGS_OFFSET,
SVE_SIG_REGS_SIZE(vq));
if (err)
- goto out_preempt;
+ return err;
/* copy the FP and status/control registers */
/* restore_sigframe() already checked that user->fpsimd != NULL. */
@@ -279,13 +277,13 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
__get_user_error(fpsimd.fpsr, &user->fpsimd->fpsr, err);
__get_user_error(fpsimd.fpcr, &user->fpsimd->fpcr, err);
+ barrier();
+ set_thread_flag(TIF_SVE);
+
/* load the hardware registers from the fpsimd_state structure */
if (!err)
fpsimd_update_current_state(&fpsimd);
-out_preempt:
- preempt_enable();
-
return err;
}
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
The base procedure call standard for the Scalable Vector Extension
defines all of the SVE programmer's model state (Z0-31, P0-15, FFR)
as caller-save, except for that subset of the state that aliases
FPSIMD state.
System calls from userspace will almost always be made through C
library wrappers -- as a consequence of the PCS there will thus
rarely if ever be any live SVE state at syscall entry in practice.
This gives us an opportinity to make SVE explicitly caller-save
around SVC and so stop carrying around the SVE state for tasks that
use SVE only occasionally (say, by calling a library).
Note that FPSIMD state will still be preserved around SVC.
As a crude heuristic to avoid pathological cases where a thread
that uses SVE frequently has to fault back into the kernel again to
re-enable SVE after a syscall, we switch the thread back to
FPSIMD-only context tracking only if the context is actually
switched out before returning to userspace.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 5834f81..2e1056e 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -203,6 +203,23 @@ static void task_fpsimd_load(struct task_struct *task)
static void task_fpsimd_save(struct task_struct *task)
{
if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+ task_pt_regs(task)->syscallno != ~0UL &&
+ test_tsk_thread_flag(task, TIF_SVE)) {
+ unsigned long tmp;
+
+ clear_tsk_thread_flag(task, TIF_SVE);
+
+ /* Trap if the task tries to use SVE again: */
+ asm volatile (
+ "mrs %[tmp], cpacr_el1\n\t"
+ "bic %[tmp], %[tmp], %[mask]\n\t"
+ "msr cpacr_el1, %[tmp]"
+ : [tmp] "=r" (tmp)
+ : [mask] "i" (CPACR_EL1_ZEN_EL0EN)
+ );
+ }
+
+ if (IS_ENABLED(CONFIG_ARM64_SVE) &&
test_tsk_thread_flag(task, TIF_SVE))
sve_save_state(__task_pffr(task),
&task->thread.fpsimd_state.fpsr);
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 23/29] arm64/sve: Move ZEN handling to the common task_fpsimd_load() path
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
Currently, ZEN is handled only in fpsimd_restore_current_state(),
which is not sufficient since it applies only in certain
situations.
Since all the relevant paths call task_fpsimd_load(), this patch
moves the ZEN handling there.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/fpsimd.c | 48 +++++++++++++++++++-----------------
2 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 2deac86..6819d08 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -133,6 +133,7 @@ static inline struct thread_info *current_thread_info(void)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_SVE (1 << TIF_SVE)
#define _TIF_32BIT (1 << TIF_32BIT)
#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index cad86e5..5834f81 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -102,21 +102,24 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
#ifdef CONFIG_ARM64_SVE
static void task_fpsimd_to_sve(struct task_struct *task);
+static void task_fpsimd_load(struct task_struct *task);
void do_sve_acc(unsigned int esr, struct pt_regs *regs)
{
- unsigned long tmp;
+ if (test_and_set_thread_flag(TIF_SVE)) {
+ unsigned long tmp;
+
+ asm ("mrs %0, cpacr_el1" : "=r" (tmp));
- if (test_and_set_thread_flag(TIF_SVE))
+ printk(KERN_INFO "%s: Strange, ZEN=%u\n",
+ __func__, (unsigned int)((tmp >> 16) & 3));
BUG();
+ }
BUG_ON(is_compat_task());
task_fpsimd_to_sve(current);
-
- asm ("mrs %0, cpacr_el1" : "=r" (tmp));
- asm volatile ("msr cpacr_el1, %0" :: "r" (tmp | (1 << 17)));
- /* Serialised by exception return to user */
+ task_fpsimd_load(current);
}
#endif /* CONFIG_ARM64_SVE */
@@ -178,6 +181,23 @@ static void task_fpsimd_load(struct task_struct *task)
&task->thread.fpsimd_state.fpsr);
else
fpsimd_load_state(&task->thread.fpsimd_state);
+
+ /*
+ * Flip SVE enable for userspace if it doesn't match the
+ * current_task.
+ */
+ if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE)) {
+ unsigned int tmp, flags;
+
+ asm ("mrs %0, cpacr_el1" : "=r" (tmp));
+ flags = task_thread_info(task)->flags;
+ BUILD_BUG_ON(_TIF_SVE != CPACR_EL1_ZEN_EL0EN);
+ if ((tmp ^ (unsigned long)flags) & _TIF_SVE) {
+ tmp ^= _TIF_SVE;
+ asm volatile ("msr cpacr_el1, %0" :: "r" (tmp));
+ /* Serialised by exception return to user */
+ }
+ }
}
static void task_fpsimd_save(struct task_struct *task)
@@ -306,27 +326,11 @@ void fpsimd_restore_current_state(void)
{
preempt_disable();
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
- unsigned long tmp;
- unsigned long flags;
-
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
task_fpsimd_load(current);
this_cpu_write(fpsimd_last_state, st);
st->cpu = smp_processor_id();
-
- if (IS_ENABLED(CONFIG_ARM64_SVE)) {
- /*
- * Flip SVE enable for userspace if it doesn't
- * match the current_task.
- */
- asm ("mrs %0, cpacr_el1" : "=r" (tmp));
- flags = current_thread_info()->flags;
- if ((tmp ^ (unsigned long)flags) & (1 << 17)) {
- tmp ^= 1 << 17;
- asm volatile ("msr cpacr_el1, %0" :: "r" (tmp));
- }
- }
}
preempt_enable();
}
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 22/29] arm64/sve: Implement FPSIMD-only context for tasks not using SVE
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
To reduce unnecessary context switch overhead, we don't need to
switch the whole SVE state for tasks that are not using it.
This patch restores the FPSIMD-only behaviour for tasks that have
never used SVE.
Note that coredumps and ptrace may see FPSIMD/SVE out of sync at
present -- this will be fixed later.
SVE state is saved on signal delivery only for tasks that have
used SVE. However, it should be possible to add SVE state on
return from a signal handler when the task didn't have any SVE
state previously. The caller may need to add its own SVE record
to the signal frame in this case.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 34 +++++++++++++++++++++++-----------
arch/arm64/kernel/signal.c | 5 ++++-
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 40566a9..cad86e5 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -100,6 +100,9 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
}
#ifdef CONFIG_ARM64_SVE
+
+static void task_fpsimd_to_sve(struct task_struct *task);
+
void do_sve_acc(unsigned int esr, struct pt_regs *regs)
{
unsigned long tmp;
@@ -107,11 +110,16 @@ void do_sve_acc(unsigned int esr, struct pt_regs *regs)
if (test_and_set_thread_flag(TIF_SVE))
BUG();
+ BUG_ON(is_compat_task());
+
+ task_fpsimd_to_sve(current);
+
asm ("mrs %0, cpacr_el1" : "=r" (tmp));
asm volatile ("msr cpacr_el1, %0" :: "r" (tmp | (1 << 17)));
/* Serialised by exception return to user */
}
-#endif
+
+#endif /* CONFIG_ARM64_SVE */
/*
* Raise a SIGFPE for the current process.
@@ -164,7 +172,8 @@ extern void *__task_pffr(struct task_struct *task);
static void task_fpsimd_load(struct task_struct *task)
{
- if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE))
+ if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+ test_tsk_thread_flag(task, TIF_SVE))
sve_load_state(__task_pffr(task),
&task->thread.fpsimd_state.fpsr);
else
@@ -173,7 +182,8 @@ static void task_fpsimd_load(struct task_struct *task)
static void task_fpsimd_save(struct task_struct *task)
{
- if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE))
+ if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+ test_tsk_thread_flag(task, TIF_SVE))
sve_save_state(__task_pffr(task),
&task->thread.fpsimd_state.fpsr);
else
@@ -202,11 +212,9 @@ void fpsimd_thread_switch(struct task_struct *next)
if (__this_cpu_read(fpsimd_last_state) == st
&& st->cpu == smp_processor_id())
- clear_ti_thread_flag(task_thread_info(next),
- TIF_FOREIGN_FPSTATE);
+ clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
else
- set_ti_thread_flag(task_thread_info(next),
- TIF_FOREIGN_FPSTATE);
+ set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
}
}
@@ -285,7 +293,8 @@ static void task_sve_to_fpsimd(struct task_struct *task __always_unused) { }
void fpsimd_signal_preserve_current_state(void)
{
fpsimd_preserve_current_state();
- task_sve_to_fpsimd(current);
+ if (test_thread_flag(TIF_SVE))
+ task_sve_to_fpsimd(current);
}
/*
@@ -367,7 +376,7 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
{
preempt_disable();
- if (IS_ENABLED(CONFIG_ARM64_SVE)) {
+ if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) {
current->thread.fpsimd_state = *state;
task_fpsimd_to_sve(current);
}
@@ -408,8 +417,8 @@ void kernel_neon_begin_partial(u32 num_regs)
* interrupt context, so always save the userland SVE state
* if there is any, even for interrupts.
*/
- if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
- current->mm &&
+ if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+ test_thread_flag(TIF_SVE) && current->mm &&
!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
fpsimd_save_state(¤t->thread.fpsimd_state);
this_cpu_write(fpsimd_last_state, NULL);
@@ -532,6 +541,9 @@ static int __init fpsimd_init(void)
if (!(elf_hwcap & HWCAP_ASIMD))
pr_notice("Advanced SIMD is not implemented\n");
+ if (!(elf_hwcap & HWCAP_SVE))
+ pr_info("Scalable Vector Extension available\n");
+
return 0;
}
late_initcall(fpsimd_init);
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 129b016..2528ec1 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -259,6 +259,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
preempt_disable();
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ set_thread_flag(TIF_SVE);
BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
@@ -543,9 +544,11 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return err;
}
- if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE)) {
+ if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) {
unsigned int vq = sve_vq_from_vl(sve_get_vl());
+ BUG_ON(!(elf_hwcap & HWCAP_SVE));
+
err = sigframe_alloc(user, &user->sve_offset,
SVE_SIG_CONTEXT_SIZE(vq));
if (err)
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 21/29] arm64/sve: Enable SVE on demand for userspace
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
This patch tracks whether a task has ever attempted to use the
Scalable Vector Extension. If and only if SVE is in use by a task,
it will be enabled for userspace when scheduling the task in. For
other tasks, SVE is disabled when scheduling in.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/entry.S | 18 +++++++++++++++++-
arch/arm64/kernel/fpsimd.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index e9ea5a6..2deac86 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -117,6 +117,7 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_SYSCALL_AUDIT 9
#define TIF_SYSCALL_TRACEPOINT 10
#define TIF_SECCOMP 11
+#define TIF_SVE 17 /* Scalable Vector Extension in use */
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
#define TIF_FREEZE 19
#define TIF_RESTORE_SIGMASK 20
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 223d54a..fe20560 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -465,6 +465,10 @@ el0_sync:
b.eq el0_ia
cmp x24, #ESR_ELx_EC_FP_ASIMD // FP/ASIMD access
b.eq el0_fpsimd_acc
+#ifdef CONFIG_ARM64_SVE
+ cmp x24, #ESR_ELx_EC_SVE // SVE access
+ b.eq el0_sve_acc
+#endif
cmp x24, #ESR_ELx_EC_FP_EXC64 // FP/ASIMD exception
b.eq el0_fpsimd_exc
cmp x24, #ESR_ELx_EC_SYS64 // configurable trap
@@ -563,9 +567,21 @@ el0_fpsimd_acc:
mov x1, sp
bl do_fpsimd_acc
b ret_to_user
+#ifdef CONFIG_ARM64_SVE
+ /*
+ * Scalable Vector Extension access
+ */
+el0_sve_acc:
+ enable_dbg
+ ct_user_exit
+ mov x0, x25
+ mov x1, sp
+ bl do_sve_acc
+ b ret_to_user
+#endif
el0_fpsimd_exc:
/*
- * Floating Point or Advanced SIMD exception
+ * Floating Point, Advanced SIMD or SVE exception
*/
enable_dbg
ct_user_exit
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index cda079e..40566a9 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -99,6 +99,20 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
WARN_ON(1);
}
+#ifdef CONFIG_ARM64_SVE
+void do_sve_acc(unsigned int esr, struct pt_regs *regs)
+{
+ unsigned long tmp;
+
+ if (test_and_set_thread_flag(TIF_SVE))
+ BUG();
+
+ asm ("mrs %0, cpacr_el1" : "=r" (tmp));
+ asm volatile ("msr cpacr_el1, %0" :: "r" (tmp | (1 << 17)));
+ /* Serialised by exception return to user */
+}
+#endif
+
/*
* Raise a SIGFPE for the current process.
*/
@@ -283,11 +297,27 @@ void fpsimd_restore_current_state(void)
{
preempt_disable();
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
+ unsigned long tmp;
+ unsigned long flags;
+
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
task_fpsimd_load(current);
this_cpu_write(fpsimd_last_state, st);
st->cpu = smp_processor_id();
+
+ if (IS_ENABLED(CONFIG_ARM64_SVE)) {
+ /*
+ * Flip SVE enable for userspace if it doesn't
+ * match the current_task.
+ */
+ asm ("mrs %0, cpacr_el1" : "=r" (tmp));
+ flags = current_thread_info()->flags;
+ if ((tmp ^ (unsigned long)flags) & (1 << 17)) {
+ tmp ^= 1 << 17;
+ asm volatile ("msr cpacr_el1, %0" :: "r" (tmp));
+ }
+ }
}
preempt_enable();
}
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 20/29] arm64/sve: traps: Add descriptive string for SVE exceptions
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
In preparation for SVE trapping in userspace, let's print something
relevant instead of "UNREGOCNIZED EC" when an unhandled SVE
exception occurs.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/include/asm/esr.h | 3 ++-
arch/arm64/kernel/traps.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index d14c478..87729f3 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -42,7 +42,8 @@
#define ESR_ELx_EC_HVC64 (0x16)
#define ESR_ELx_EC_SMC64 (0x17)
#define ESR_ELx_EC_SYS64 (0x18)
-/* Unallocated EC: 0x19 - 0x1E */
+#define ESR_ELx_EC_SVE (0x19)
+/* Unallocated EC: 0x1A - 0x1E */
#define ESR_ELx_EC_IMP_DEF (0x1f)
#define ESR_ELx_EC_IABT_LOW (0x20)
#define ESR_ELx_EC_IABT_CUR (0x21)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index c9986b3..aaab1dd 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -569,6 +569,7 @@ static const char *esr_class_str[] = {
[ESR_ELx_EC_HVC64] = "HVC (AArch64)",
[ESR_ELx_EC_SMC64] = "SMC (AArch64)",
[ESR_ELx_EC_SYS64] = "MSR/MRS (AArch64)",
+ [ESR_ELx_EC_SVE] = "SVE",
[ESR_ELx_EC_IMP_DEF] = "EL3 IMP DEF",
[ESR_ELx_EC_IABT_LOW] = "IABT (lower EL)",
[ESR_ELx_EC_IABT_CUR] = "IABT (current EL)",
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 19/29] arm64/sve: Avoid corruption when replacing the SVE state
From: Dave Martin @ 2016-11-25 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-1-git-send-email-Dave.Martin@arm.com>
If preemption occurs during replacement of the whole SVE state,
as occurs during execve() or rt_sigreturn(), then some or all of
the new state for the thread can be lost, due to erroneous saving
of the pre-existing state over the new data.
This patch disables preemption around the affected operations to
avoid this failure mode.
This should be reexamined later if the impact on preemption latency
proves to be excessive.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
arch/arm64/kernel/fpsimd.c | 4 ++++
arch/arm64/kernel/signal.c | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index b1a8d3e..cda079e 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -198,6 +198,8 @@ void fpsimd_thread_switch(struct task_struct *next)
void fpsimd_flush_thread(void)
{
+ preempt_disable();
+
fpsimd_flush_task_state(current);
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
@@ -213,6 +215,8 @@ void fpsimd_flush_thread(void)
}
set_thread_flag(TIF_FOREIGN_FPSTATE);
+
+ preempt_enable();
}
/*
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 2697d09..129b016 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -256,6 +256,10 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
if (vl != sve_get_vl())
return -EINVAL;
+ preempt_disable();
+
+ set_thread_flag(TIF_FOREIGN_FPSTATE);
+
BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
BUG_ON(SVE_SIG_FFR_OFFSET(vq) - SVE_SIG_REGS_OFFSET !=
@@ -265,7 +269,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
SVE_SIG_REGS_OFFSET,
SVE_SIG_REGS_SIZE(vq));
if (err)
- return err;
+ goto out_preempt;
/* copy the FP and status/control registers */
/* restore_sigframe() already checked that user->fpsimd != NULL. */
@@ -278,6 +282,9 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
if (!err)
fpsimd_update_current_state(&fpsimd);
+out_preempt:
+ preempt_enable();
+
return err;
}
--
2.1.4
^ permalink raw reply related
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