* [PULL 00/19] KVM/ARM Fixes for v4.15
From: Christoffer Dall @ 2017-12-04 13:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Christoffer Dall <christoffer.dall@linaro.org>
Hi Paolo and Radim,
Here's the first round of fixes for KVM/ARM for v4.15. This is a fairly large
set of fixes, partially because we spotted a handful of issues from running the
SMATCH static analysis on the code (thanks to AKASHI Takahiro).
In more details, this pull request fixes:
- A number of issues in the vgic discovered using SMATCH
- A bit one-off calculation in out stage base address mask (32-bit and
64-bit)
- Fixes to single-step debugging instructions that trap for other
reasons such as MMMIO aborts
- Printing unavailable hyp mode as error
- Potential spinlock deadlock in the vgic
- Avoid calling vgic vcpu free more than once
- Broken bit calculation for big endian systems
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-fixes-for-v4.15-1
for you to fetch changes up to fc396e066318c0a02208c1d3f0b62950a7714999:
KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion (2017-12-04 14:25:33 +0100)
Thanks,
-Christoffer
Alex Benn?e (5):
KVM: arm/arm64: debug: Introduce helper for single-step
kvm: arm64: handle single-stepping trapped instructions
kvm: arm64: handle single-step of userspace mmio instructions
kvm: arm64: handle single-step during SError exceptions
kvm: arm64: handle single-step of hyp emulated mmio instructions
Andre Przywara (1):
KVM: arm/arm64: VGIC: extend !vgic_is_initialized guard
Andrew Jones (1):
KVM: arm/arm64: kvm_arch_destroy_vm cleanups
Ard Biesheuvel (1):
kvm: arm: don't treat unavailable HYP mode as an error
Christoffer Dall (3):
KVM: arm/arm64: Don't enable/disable physical timer access on VHE
KVM: arm/arm64: Avoid attempting to load timer vgic state without a
vgic
KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion
Kristina Martsenko (1):
arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
Marc Zyngier (7):
KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation
KVM: arm/arm64: vgic: Preserve the revious read from the pending table
KVM: arm/arm64: vgic-its: Preserve the revious read from the pending
table
KVM: arm/arm64: vgic-its: Check result of allocation before use
KVM: arm/arm64: vgic-v4: Only perform an unmap for valid vLPIs
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
KVM: arm/arm64: Fix spinlock acquisition in vgic_set_owner
arch/arm/include/asm/kvm_arm.h | 3 +--
arch/arm/include/asm/kvm_host.h | 5 ++++
arch/arm64/include/asm/kvm_arm.h | 3 +--
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/debug.c | 21 +++++++++++++++
arch/arm64/kvm/handle_exit.c | 57 ++++++++++++++++++++++++++++-----------
arch/arm64/kvm/hyp/switch.c | 37 ++++++++++++++++++++-----
include/kvm/arm_arch_timer.h | 3 ---
virt/kvm/arm/arch_timer.c | 11 +++-----
virt/kvm/arm/arm.c | 7 +++--
virt/kvm/arm/hyp/timer-sr.c | 48 ++++++++++++++-------------------
virt/kvm/arm/hyp/vgic-v2-sr.c | 4 ---
virt/kvm/arm/vgic/vgic-irqfd.c | 3 +--
virt/kvm/arm/vgic/vgic-its.c | 4 ++-
virt/kvm/arm/vgic/vgic-v3.c | 2 +-
virt/kvm/arm/vgic/vgic-v4.c | 6 +++--
virt/kvm/arm/vgic/vgic.c | 8 +++---
17 files changed, 144 insertions(+), 79 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH 3/3] arm64/sve: KVM: Avoid dereference of dead task during guest entry
From: Ard Biesheuvel @ 2017-12-04 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512141582-17474-4-git-send-email-Dave.Martin@arm.com>
On 1 December 2017 at 15:19, Dave Martin <Dave.Martin@arm.com> wrote:
> When deciding whether to invalidate FPSIMD state cached in the cpu,
> the backend function sve_flush_cpu_state() attempts to dereference
> __this_cpu_read(fpsimd_last_state). However, this is not safe:
> there is no guarantee that the pointer is still valid, because the
> task could have exited in the meantime. For this reason, this
> percpu pointer should only be assigned or compared, never
> dereferenced.
>
Doesn't that mean the pointer could also be pointing to the
fpsimd_state of a newly created task that is completely unrelated?
IOW, are you sure comparison is safe?
> This means that we need another means to get the appropriate value
> of TIF_SVE for the associated task.
>
> This patch solves this issue by adding a cached copy of the TIF_SVE
> flag in fpsimd_last_state, which we can check without dereferencing
> the task pointer.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kernel/fpsimd.c | 28 ++++++++++++++++------------
> 1 file changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 007140b..3dc8058 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -114,7 +114,12 @@
> * returned from the 2nd syscall yet, TIF_FOREIGN_FPSTATE is still set so
> * whatever is in the FPSIMD registers is not saved to memory, but discarded.
> */
> -static DEFINE_PER_CPU(struct fpsimd_state *, fpsimd_last_state);
> +struct fpsimd_last_state_struct {
> + struct fpsimd_state *st;
> + bool sve_in_use;
> +};
> +
> +static DEFINE_PER_CPU(struct fpsimd_last_state_struct, fpsimd_last_state);
>
> /* Default VL for tasks that don't set it explicitly: */
> static int sve_default_vl = -1;
> @@ -905,7 +910,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> */
> struct fpsimd_state *st = &next->thread.fpsimd_state;
>
> - if (__this_cpu_read(fpsimd_last_state) == st
> + if (__this_cpu_read(fpsimd_last_state.st) == st
> && st->cpu == smp_processor_id())
> clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
> else
> @@ -997,9 +1002,12 @@ void fpsimd_signal_preserve_current_state(void)
> */
> static void fpsimd_bind_to_cpu(void)
> {
> + struct fpsimd_last_state_struct *last =
> + this_cpu_ptr(&fpsimd_last_state);
> struct fpsimd_state *st = ¤t->thread.fpsimd_state;
>
> - __this_cpu_write(fpsimd_last_state, st);
> + last->st = st;
> + last->sve_in_use = test_thread_flag(TIF_SVE);
> st->cpu = smp_processor_id();
> }
>
> @@ -1057,7 +1065,7 @@ void fpsimd_flush_task_state(struct task_struct *t)
>
> static inline void fpsimd_flush_cpu_state(void)
> {
> - __this_cpu_write(fpsimd_last_state, NULL);
> + __this_cpu_write(fpsimd_last_state.st, NULL);
> }
>
> /*
> @@ -1070,14 +1078,10 @@ static inline void fpsimd_flush_cpu_state(void)
> #ifdef CONFIG_ARM64_SVE
> void sve_flush_cpu_state(void)
> {
> - struct fpsimd_state *const fpstate = __this_cpu_read(fpsimd_last_state);
> - struct task_struct *tsk;
> -
> - if (!fpstate)
> - return;
> + struct fpsimd_last_state_struct const *last =
> + this_cpu_ptr(&fpsimd_last_state);
>
> - tsk = container_of(fpstate, struct task_struct, thread.fpsimd_state);
> - if (test_tsk_thread_flag(tsk, TIF_SVE))
> + if (last->st && last->sve_in_use)
> fpsimd_flush_cpu_state();
> }
> #endif /* CONFIG_ARM64_SVE */
> @@ -1272,7 +1276,7 @@ static inline void fpsimd_pm_init(void) { }
> #ifdef CONFIG_HOTPLUG_CPU
> static int fpsimd_cpu_dead(unsigned int cpu)
> {
> - per_cpu(fpsimd_last_state, cpu) = NULL;
> + per_cpu(fpsimd_last_state.st, cpu) = NULL;
> return 0;
> }
>
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 2/3] arm64: fpsimd: Abstract out binding of task's fpsimd context to the cpu.
From: Ard Biesheuvel @ 2017-12-04 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512141582-17474-3-git-send-email-Dave.Martin@arm.com>
On 1 December 2017 at 15:19, Dave Martin <Dave.Martin@arm.com> wrote:
> There is currently some duplicate logic to associate current's
> FPSIMD context with the cpu when loading FPSIMD state into the cpu
> regs.
>
> Subsequent patches will update that logic, so in order to ensure it
> only needs to be done in one place, this patch factors the relevant
> code out into a new function fpsimd_bind_to_cpu().
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/fpsimd.c | 25 +++++++++++++++----------
> 1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 143b3e7..007140b 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -992,6 +992,18 @@ void fpsimd_signal_preserve_current_state(void)
> }
>
> /*
> + * Associate current's FPSIMD context with this cpu
> + * Preemption must be disabled when calling this function.
> + */
> +static void fpsimd_bind_to_cpu(void)
> +{
> + struct fpsimd_state *st = ¤t->thread.fpsimd_state;
> +
> + __this_cpu_write(fpsimd_last_state, st);
> + st->cpu = smp_processor_id();
> +}
> +
> +/*
> * Load the userland FPSIMD state of 'current' from memory, but only if the
> * FPSIMD state already held in the registers is /not/ the most recent FPSIMD
> * state of 'current'
> @@ -1004,11 +1016,8 @@ void fpsimd_restore_current_state(void)
> local_bh_disable();
>
> if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> - struct fpsimd_state *st = ¤t->thread.fpsimd_state;
> -
> task_fpsimd_load();
> - __this_cpu_write(fpsimd_last_state, st);
> - st->cpu = smp_processor_id();
> + fpsimd_bind_to_cpu();
> }
>
> local_bh_enable();
> @@ -1032,12 +1041,8 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
> }
> task_fpsimd_load();
>
> - if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
> - struct fpsimd_state *st = ¤t->thread.fpsimd_state;
> -
> - __this_cpu_write(fpsimd_last_state, st);
> - st->cpu = smp_processor_id();
> - }
> + if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE))
> + fpsimd_bind_to_cpu();
>
> local_bh_enable();
> }
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply
* [PATCH v3] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-04 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512271374.17567.164.camel@mhfsdcap03>
On 12/2/2017 10:22 PM, Chunfeng Yun wrote:
> On Fri, 2017-12-01 at 10:44 -0500, Adam Wallis wrote:
>> The xHCI driver currently has the IMOD set to 160, which
>> translates to an IMOD interval of 40,000ns (160 * 250)ns
>>
>> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
>> introduced a QUIRK for the MTK platform to adjust this interval to 20,
>> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
>> due to the fact that the MTK controller IMOD interval is 8 times
>> as much as defined in xHCI spec.
>>
>> Instead of adding more quirk bits for additional platforms, this patch
>> introduces the ability for vendors to set the IMOD_INTERVAL as is
>> optimal for their platform. By using device_property_read_u32() on
>> "imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
>> no interval is specified, the default of 40,000ns (IMOD=160) will be
>> used.
>>
>> No bounds checking has been implemented due to the fact that a vendor
>> may have violated the spec and would need to specify a value outside of
>> the max 8,000 IRQs/second limit specified in the xHCI spec.
>>
>> Signed-off-by: Adam Wallis <awallis@codeaurora.org>
>> ---
>> changes from v2:
>> * Added PCI default value [Mathias]
>> * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
>> * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
>> * Updated bindings Documentation to use proper units [Rob Herring]
>> * Added imod-interval description and example to MTK binding documentation
>> changes from v1:
>> * Removed device_property_read_u32() per suggestion from greg k-h
>> * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>>
>> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>> drivers/usb/host/xhci-mtk.c | 9 +++++++++
>> drivers/usb/host/xhci-pci.c | 3 +++
>> drivers/usb/host/xhci-plat.c | 4 ++++
>> drivers/usb/host/xhci.c | 7 ++-----
>> drivers/usb/host/xhci.h | 2 ++
>> 7 files changed, 23 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>> index 3059596..45bbf18 100644
>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>> @@ -46,6 +46,7 @@ Optional properties:
>> - pinctrl-names : a pinctrl state named "default" must be defined
>> - pinctrl-0 : pin control group
>> See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>> + - imod-interval: Default interval is 5000ns
> I think, as Rob suggested before, recommend to have a unit suffix
> appended to the property name.
> s/imod-interval/imod-interval-ns
Thanks, I definitely misunderstood his comments the first go around. I will make
the change.
>>
>> Example:
>> usb30: usb at 11270000 {
>> @@ -66,6 +67,7 @@ usb30: usb at 11270000 {
>> usb3-lpm-capable;
>> mediatek,syscon-wakeup = <&pericfg>;
>> mediatek,wakeup-src = <1>;
>> + imod-interval = <10000>;
>> };
>>
>> 2nd: dual-role mode with xHCI driver
>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> index ae6e484..89b68f1 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>> @@ -29,6 +29,7 @@ Optional properties:
>> - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>> - quirk-broken-port-ped: set if the controller has broken port disable mechanism
>> + - imod-interval: Default interval is 40000ns
>>
>> Example:
>> usb at f0931000 {
>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
>> index b62a1d2..278ea3b 100644
>> --- a/drivers/usb/host/xhci-mtk.c
>> +++ b/drivers/usb/host/xhci-mtk.c
>> @@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>>
>> xhci = hcd_to_xhci(hcd);
>> xhci->main_hcd = hcd;
>> +
>> + /*
>> + * imod_interval is the interrupt modulation value in nanoseconds.
>> + * The increment interval is 8 times as much as that defined in
>> + * the xHCI spec on MTK's controller.
>> + */
>> + xhci->imod_interval = 5000;
>> + device_property_read_u32(dev, "imod-interval", &xhci->imod_interval);
>> +
>> xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
>> dev_name(dev), hcd);
>> if (!xhci->shared_hcd) {
>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>> index 7ef1274..efbe57b 100644
>> --- a/drivers/usb/host/xhci-pci.c
>> +++ b/drivers/usb/host/xhci-pci.c
>> @@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
>> if (!xhci->sbrn)
>> pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
>>
>> + /* imod_interval is the interrupt modulation value in nanoseconds. */
>> + xhci->imod_interval = 40000;
>> +
>> retval = xhci_gen_setup(hcd, xhci_pci_quirks);
>> if (retval)
>> return retval;
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index 09f164f..b78be87 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -269,6 +269,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
>> if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
>> xhci->quirks |= XHCI_BROKEN_PORT_PED;
>>
>> + /* imod_interval is the interrupt modulation value in nanoseconds. */
>> + xhci->imod_interval = 40000;
>> + device_property_read_u32(sysdev, "imod-interval", &xhci->imod_interval);
>> +
>> hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
>> if (IS_ERR(hcd->usb_phy)) {
>> ret = PTR_ERR(hcd->usb_phy);
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index 2424d30..0b7755b 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
>> "// Set the interrupt modulation register");
>> temp = readl(&xhci->ir_set->irq_control);
>> temp &= ~ER_IRQ_INTERVAL_MASK;
>> - /*
>> - * the increment interval is 8 times as much as that defined
>> - * in xHCI spec on MTK's controller
>> - */
>> - temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
>> + temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
>> +
>> writel(temp, &xhci->ir_set->irq_control);
>>
>> /* Set the HCD state before we enable the irqs */
>> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
>> index 99a014a..2a4177b 100644
>> --- a/drivers/usb/host/xhci.h
>> +++ b/drivers/usb/host/xhci.h
>> @@ -1717,6 +1717,8 @@ struct xhci_hcd {
>> u8 max_interrupters;
>> u8 max_ports;
>> u8 isoc_threshold;
>> + /* imod_interval in ns (I * 250ns) */
>> + u32 imod_interval;
>> int event_ring_max;
>> /* 4KB min, 128MB max */
>> int page_size;
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-12-04 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82fc73c9-96d5-adc5-e2d1-d777ed861119@linux.intel.com>
On 12/4/2017 3:57 AM, Mathias Nyman wrote:
> On 03.12.2017 05:22, Chunfeng Yun wrote:
>> On Fri, 2017-12-01 at 10:44 -0500, Adam Wallis wrote:
>>> The xHCI driver currently has the IMOD set to 160, which
>>> translates to an IMOD interval of 40,000ns (160 * 250)ns
>>>
>>> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
>>> introduced a QUIRK for the MTK platform to adjust this interval to 20,
>>> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
>>> due to the fact that the MTK controller IMOD interval is 8 times
>>> as much as defined in xHCI spec.
>>>
>>> Instead of adding more quirk bits for additional platforms, this patch
>>> introduces the ability for vendors to set the IMOD_INTERVAL as is
>>> optimal for their platform. By using device_property_read_u32() on
>>> "imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
>>> no interval is specified, the default of 40,000ns (IMOD=160) will be
>>> used.
>>>
>>> No bounds checking has been implemented due to the fact that a vendor
>>> may have violated the spec and would need to specify a value outside of
>>> the max 8,000 IRQs/second limit specified in the xHCI spec.
>>>
>>> Signed-off-by: Adam Wallis <awallis@codeaurora.org>
>>> ---
>>> changes from v2:
>>> ?? * Added PCI default value [Mathias]
>>> ?? * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
>>> ?? * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
>>> ?? * Updated bindings Documentation to use proper units [Rob Herring]
>>> ?? * Added imod-interval description and example to MTK binding documentation
>>> changes from v1:
>>> ?? * Removed device_property_read_u32() per suggestion from greg k-h
>>> ?? * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>>>
>>> ? Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
>>> ? Documentation/devicetree/bindings/usb/usb-xhci.txt????????? | 1 +
>>> ? drivers/usb/host/xhci-mtk.c???????????????????????????????? | 9 +++++++++
>>> ? drivers/usb/host/xhci-pci.c???????????????????????????????? | 3 +++
>>> ? drivers/usb/host/xhci-plat.c??????????????????????????????? | 4 ++++
>>> ? drivers/usb/host/xhci.c???????????????????????????????????? | 7 ++-----
>>> ? drivers/usb/host/xhci.h???????????????????????????????????? | 2 ++
>>> ? 7 files changed, 23 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> index 3059596..45bbf18 100644
>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> @@ -46,6 +46,7 @@ Optional properties:
>>> ?? - pinctrl-names : a pinctrl state named "default" must be defined
>>> ?? - pinctrl-0 : pin control group
>>> ????? See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>>> + - imod-interval: Default interval is 5000ns
>> I think, as Rob suggested before, recommend to have a unit suffix
>> appended to the property name.
>> s/imod-interval/imod-interval-ns
>> ?
>>> ? ? Example:
>>> ? usb30: usb at 11270000 {
>>> @@ -66,6 +67,7 @@ usb30: usb at 11270000 {
>>> ????? usb3-lpm-capable;
>>> ????? mediatek,syscon-wakeup = <&pericfg>;
>>> ????? mediatek,wakeup-src = <1>;
>>> +??? imod-interval = <10000>;
>>> ? };
>>> ? ? 2nd: dual-role mode with xHCI driver
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> index ae6e484..89b68f1 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> @@ -29,6 +29,7 @@ Optional properties:
>>> ??? - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>>> ??? - usb3-lpm-capable: determines if platform is USB3 LPM capable
>>> ??? - quirk-broken-port-ped: set if the controller has broken port disable
>>> mechanism
>>> +? - imod-interval: Default interval is 40000ns
>>> ? ? Example:
>>> ????? usb at f0931000 {
>>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
>>> index b62a1d2..278ea3b 100644
>>> --- a/drivers/usb/host/xhci-mtk.c
>>> +++ b/drivers/usb/host/xhci-mtk.c
>>> @@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>>> ? ????? xhci = hcd_to_xhci(hcd);
>>> ????? xhci->main_hcd = hcd;
>>> +
>>> +??? /*
>>> +???? * imod_interval is the interrupt modulation value in nanoseconds.
>>> +???? * The increment interval is 8 times as much as that defined in
>>> +???? * the xHCI spec on MTK's controller.
>>> +???? */
>>> +??? xhci->imod_interval = 5000;
>>> +??? device_property_read_u32(dev, "imod-interval", &xhci->imod_interval);
>>> +
>>> ????? xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
>>> ????????????? dev_name(dev), hcd);
>>> ????? if (!xhci->shared_hcd) {
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 7ef1274..efbe57b 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
>>> ????? if (!xhci->sbrn)
>>> ????????? pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
>>> ? +??? /* imod_interval is the interrupt modulation value in nanoseconds. */
>>> +??? xhci->imod_interval = 40000;
>>> +
>>> ????? retval = xhci_gen_setup(hcd, xhci_pci_quirks);
>>> ????? if (retval)
>>> ????????? return retval;
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index 09f164f..b78be87 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -269,6 +269,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>> ????? if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
>>> ????????? xhci->quirks |= XHCI_BROKEN_PORT_PED;
>>> ? +??? /* imod_interval is the interrupt modulation value in nanoseconds. */
>>> +??? xhci->imod_interval = 40000;
>>> +??? device_property_read_u32(sysdev, "imod-interval", &xhci->imod_interval);
>>> +
>>> ????? hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
>>> ????? if (IS_ERR(hcd->usb_phy)) {
>>> ????????? ret = PTR_ERR(hcd->usb_phy);
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index 2424d30..0b7755b 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
>>> ????????????? "// Set the interrupt modulation register");
>
> Just noticed the driver has all the time incorrectly used the word "modulation"
> instead
> of "moderation".
>
> If you do the bindings change that Chunfeng pointed out above could you also change
> the "modulation" to "moderation" in this patch.
Sure thing, I will make the change for this patch.
>
> Don't worry about changing the old ones. There's a cleanup patch on its way that
> will remove most of them anyway.
>
> Otherwise the xhci parts look good to me.
>
> -Mathias
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at? http://vger.kernel.org/majordomo-info.html
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: Add dma_mask to dm365's eDMA device
From: Alejandro Mery @ 2017-12-04 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204133359.45625-1-amery@hanoverdisplays.com>
as previously done by cef5b0da4019358cb03c9b0a964d4d63cd7deaf6 for other davinci SoCs
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
arch/arm/mach-davinci/dm365.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 855e0a57b219..90858bc9dd18 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -928,6 +928,7 @@ static struct resource edma_resources[] = {
static const struct platform_device_info dm365_edma_device __initconst = {
.name = "edma",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
.res = edma_resources,
.num_res = ARRAY_SIZE(edma_resources),
.data = &dm365_edma_pdata,
--
2.15.0
^ permalink raw reply related
* [PATCH 1/2] ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA
From: Alejandro Mery @ 2017-12-04 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204133359.45625-1-amery@hanoverdisplays.com>
as it was done by 7ab388e85faa97a35d520720269e7c8e00ad54a0 for other davinci SoCs
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
arch/arm/mach-davinci/dm365.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 8be04ec95adf..855e0a57b219 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -925,12 +925,13 @@ static struct resource edma_resources[] = {
/* not using TC*_ERR */
};
-static struct platform_device dm365_edma_device = {
- .name = "edma",
- .id = 0,
- .dev.platform_data = &dm365_edma_pdata,
- .num_resources = ARRAY_SIZE(edma_resources),
- .resource = edma_resources,
+static const struct platform_device_info dm365_edma_device __initconst = {
+ .name = "edma",
+ .id = 0,
+ .res = edma_resources,
+ .num_res = ARRAY_SIZE(edma_resources),
+ .data = &dm365_edma_pdata,
+ .size_data = sizeof(&dm365_edma_pdata),
};
static struct resource dm365_asp_resources[] = {
@@ -1428,13 +1429,18 @@ int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
static int __init dm365_init_devices(void)
{
+ struct platform_device *edma_pdev;
int ret = 0;
if (!cpu_is_davinci_dm365())
return 0;
davinci_cfg_reg(DM365_INT_EDMA_CC);
- platform_device_register(&dm365_edma_device);
+ edma_pdev = platform_device_register_full(&dm365_edma_device);
+ if (IS_ERR(edma_pdev)) {
+ pr_warn("%s: Failed to register eDMA\n", __func__);
+ return PTR_ERR(edma_pdev);
+ }
platform_device_register(&dm365_mdio_device);
platform_device_register(&dm365_emac_device);
--
2.15.0
^ permalink raw reply related
* [PATCH 0/2] ARM: davinci: fix eDMA probing for dm365
From: Alejandro Mery @ 2017-12-04 13:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi, as an intermediate step toward migrating a davinci dm365 based product from 2.6.32.71
to 4.14(.3+) I'm trying to get the dm365 evm (evaluation board) to work
The very first problem is `edma: probe of edma.0 failed with error -5` caused by dm365 not
been included on some refactoring done by Peter Ujfalusi in 2015 which got solved by the
cherry-picking the following changes into dm365.c
* cef5b0da4019 2015-10-14 Peter Ujfalusi ARM: davinci: Add dma_mask to eDMA devices
* 7ab388e85faa 2015-10-14 Peter Ujfalusi ARM: davinci: Use platform_device_register_full() to create pdev for eDMA
^ permalink raw reply
* [PATCH] ARM: debug: add stm32 low-level debug support
From: Ludovic Barre @ 2017-12-04 13:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Ludovic Barre <ludovic.barre@st.com>
This adds low-level debug support on USART1 for STM32F4
and STM32F7. Compiled via 'CONFIG_DEBUG_LL' and 'CONFIG_EARLY_PRINTK'.
Enabled via 'earlyprintk' in bootargs.
Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
---
arch/arm/Kconfig.debug | 25 +++++++++++++++++++++++++
arch/arm/include/debug/stm32.S | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
create mode 100644 arch/arm/include/debug/stm32.S
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 17685e1..9469c58 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1140,6 +1140,26 @@ choice
If unsure, say N.
+ config STM32F4_DEBUG_UART
+ bool "Use STM32F4 UART for low-level debug"
+ depends on ARCH_STM32
+ select DEBUG_STM32_UART
+ help
+ Say Y here if you want kernel low-level debugging support
+ on STM32 based platforms.
+
+ If unsure, say N.
+
+ config STM32F7_DEBUG_UART
+ bool "Use STM32F7 UART for low-level debug"
+ depends on ARCH_STM32
+ select DEBUG_STM32_UART
+ help
+ Say Y here if you want kernel low-level debugging support
+ on STM32 based platforms.
+
+ If unsure, say N.
+
config TEGRA_DEBUG_UART_AUTO_ODMDATA
bool "Kernel low-level debugging messages via Tegra UART via ODMDATA"
depends on ARCH_TEGRA
@@ -1424,6 +1444,10 @@ config DEBUG_STI_UART
bool
depends on ARCH_STI
+config DEBUG_STM32_UART
+ bool
+ depends on ARCH_STM32
+
config DEBUG_SIRFSOC_UART
bool
depends on ARCH_SIRF
@@ -1472,6 +1496,7 @@ config DEBUG_LL_INCLUDE
default "debug/s5pv210.S" if DEBUG_S5PV210_UART
default "debug/sirf.S" if DEBUG_SIRFSOC_UART
default "debug/sti.S" if DEBUG_STI_UART
+ default "debug/stm32.S" if DEBUG_STM32_UART
default "debug/tegra.S" if DEBUG_TEGRA_UART
default "debug/ux500.S" if DEBUG_UX500_UART
default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT
diff --git a/arch/arm/include/debug/stm32.S b/arch/arm/include/debug/stm32.S
new file mode 100644
index 0000000..4015257
--- /dev/null
+++ b/arch/arm/include/debug/stm32.S
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
+ * Author: Gerald Baeza <gerald_baeza@st.com>
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#define STM32_UART_BASE 0x40011000 /* USART1 */
+
+#ifdef CONFIG_STM32F4_DEBUG_UART
+#define STM32_USART_SR_OFF 0x00
+#define STM32_USART_TDR_OFF 0x04
+#endif
+
+#ifdef CONFIG_STM32F7_DEBUG_UART
+#define STM32_USART_SR_OFF 0x1C
+#define STM32_USART_TDR_OFF 0x28
+#endif
+
+#define STM32_USART_TC (1 << 6) /* Tx complete */
+#define STM32_USART_TXE (1 << 7) /* Tx data reg empty */
+
+ .macro addruart, rp, rv, tmp
+ ldr \rp, =STM32_UART_BASE @ physical base
+ ldr \rv, =STM32_UART_BASE @ virt base /* NoMMU */
+ .endm
+
+ .macro senduart,rd,rx
+ strb \rd, [\rx, #STM32_USART_TDR_OFF]
+ .endm
+
+ .macro waituart,rd,rx
+1001: ldr \rd, [\rx, #(STM32_USART_SR_OFF)] @ Read Status Register
+ tst \rd, #STM32_USART_TXE @ TXE = 1 = tx empty
+ beq 1001b
+ .endm
+
+ .macro busyuart,rd,rx
+1001: ldr \rd, [\rx, #(STM32_USART_SR_OFF)] @ Read Status Register
+ tst \rd, #STM32_USART_TC @ TC = 1 = tx complete
+ beq 1001b
+ .endm
--
2.7.4
^ permalink raw reply related
* [PATCH V2 3/7] PCI: make pci_flr_wait() generic and rename to pci_dev_wait()
From: Sinan Kaya @ 2017-12-04 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129173801.GD27742@infradead.org>
On 11/29/2017 12:38 PM, Christoph Hellwig wrote:
> On Mon, Nov 27, 2017 at 01:20:24AM -0500, Sinan Kaya wrote:
>> Rev 3.1 Sec 2.3.1 Request Handling Rules:
>> Valid reset conditions after which a device is permitted to return CRS
>> are:
>> * Cold, Warm, and Hot Resets,
>> * FLR
>> * A reset initiated in response to a D3hot to D0 uninitialized
>>
>> Try to reuse FLR implementation towards other reset types.
>
> Should we keep a helper for the FLR wait? If not I guess the reference
> for AF_FLR should be the PCI spec, not the PCIE spec.
>
Bjorn,
what is your opinion?
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 10/12] ARM: dts: imx6q-h100: Remove unneeded unit address
From: Lucas Stach @ 2017-12-04 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512390016-703-10-git-send-email-festevam@gmail.com>
Am Montag, den 04.12.2017, 10:20 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Remove the unneeded unit address for the port nodes in order to fix
> the following build warnings with W=1:
>
> arch/arm/boot/dts/imx6q-h100.dtb: Warning (unit_address_vs_reg): Node
> /soc/aips-bus at 2100000/i2c at 21a0000/tc358743 at f/port at 0 has a unit name,
> but no reg property
> arch/arm/boot/dts/imx6q-h100.dtb: Warning (unit_address_vs_reg): Node
> /soc/aips-bus at 2100000/mipi at 21dc000/port at 0 has a unit name, but no reg
> property
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Changes since v1:
> - None
>
> ?arch/arm/boot/dts/imx6q-h100.dts | 4 ++--
> ?1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-h100.dts
> b/arch/arm/boot/dts/imx6q-h100.dts
> index 743c11f..cc1ce46 100644
> --- a/arch/arm/boot/dts/imx6q-h100.dts
> +++ b/arch/arm/boot/dts/imx6q-h100.dts
> @@ -205,7 +205,7 @@
> ? reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
> ? /* IRQ has a wrong pull resistor which renders it
> useless??*/
> ?
> - port at 0 {
> + port {
> ? tc358743_out: endpoint {
> ? remote-endpoint = <&mipi_csi2_in>;
> ? data-lanes = <1 2 3 4>;
> @@ -348,7 +348,7 @@
> ?&mipi_csi {
> ? status = "okay";
> ?
> - port at 0 {
> + port {
> ? mipi_csi2_in: endpoint {
> ? remote-endpoint = <&tc358743_out>;
> ? data-lanes = <1 2 3 4>;
^ permalink raw reply
* [PATCH v2 02/12] ARM: dts: imx51-zii-rdu1: Add the unit addresses in sysled
From: Lucas Stach @ 2017-12-04 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512390016-703-2-git-send-email-festevam@gmail.com>
Am Montag, den 04.12.2017, 10:20 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> As described at Documentation/devicetree/bindings/mfd/mc13xxx.txt the
> reg property is mandatory, so add the corresponding unit address in
> order to fix the following build warnings with W=1:
>
> arch/arm/boot/dts/imx51-zii-rdu1.dtb: Warning (unit_address_vs_reg):
> Node /soc/aips at 70000000/spba at 70000000/ecspi at 70010000/pmic at 0/leds/sysl
> ed0 has a reg or ranges property, but no unit name
> arch/arm/boot/dts/imx51-zii-rdu1.dtb: Warning (unit_address_vs_reg):
> Node /soc/aips at 70000000/spba at 70000000/ecspi at 70010000/pmic at 0/leds/sysl
> ed1 has a reg or ranges property, but no unit name
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Changes since v1:
> - Removed 'Node /memory has a reg or ranges property, but no unit
> name' error
>
> ?arch/arm/boot/dts/imx51-zii-rdu1.dts | 4 ++--
> ?1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
> b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> index f9fdb7c..70fdcdd 100644
> --- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
> +++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> @@ -428,13 +428,13 @@
> ? #size-cells = <0>;
> ? led-control = <0x0 0x0 0x3f83f8 0x0>;
> ?
> - sysled0 {
> + sysled0 at 3 {
> ? reg = <3>;
> ? label = "system:green:status";
> ? linux,default-trigger = "default-
> on";
> ? };
> ?
> - sysled1 {
> + sysled1 at 4 {
> ? reg = <4>;
> ? label = "system:green:act";
> ? linux,default-trigger = "heartbeat";
^ permalink raw reply
* [PATCH] ARM: dts: imx6qdl-zii-rdu2: Remove device_type from PCI subnode
From: Lucas Stach @ 2017-12-04 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512234488-8760-1-git-send-email-festevam@gmail.com>
Am Samstag, den 02.12.2017, 15:08 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> device_type = "pci" should be used for the SoC level PCI controller
> and
> it is already present at imx6qdl.dtsi.
>
> Remove it from the subnode in order to fix the following build
> warnings with W=1:
>
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_bridge): Node /soc
> /pcie at 1ffc000/pci at 0 missing ranges for PCI bridge (or not a bridge)
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_bridge): Node /soc
> /pcie at 1ffc000/pci at 0 missing bus-range for PCI bridge
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (unit_address_format):
> Failed prerequisite 'pci_bridge'
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_device_reg):
> Failed prerequisite 'pci_bridge'
> arch/arm/boot/dts/imx6q-zii-rdu2.dtb: Warning (pci_device_bus_num):
> Failed prerequisite 'pci_bridge'
>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi | 1 -
> ?1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> index 5ea9949..72f52fc 100644
> --- a/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> @@ -584,7 +584,6 @@
> ?
> ? host at 0 {
> ? reg = <0 0 0 0 0>;
> - device_type = "pci";
> ?
> ? #address-cells = <3>;
> ? #size-cells = <2>;
^ permalink raw reply
* [PATCHv2 12/12] arm64: docs: document pointer authentication
From: Andrew Jones @ 2017-12-04 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204123932.pru4lw753xm7qlwb@lakrids.cambridge.arm.com>
On Mon, Dec 04, 2017 at 12:39:33PM +0000, Mark Rutland wrote:
> On Tue, Nov 28, 2017 at 04:07:26PM +0100, Andrew Jones wrote:
> > Hi Mark,
>
> Hi Drew,
>
> > On Mon, Nov 27, 2017 at 04:38:06PM +0000, Mark Rutland wrote:
> > > +Architecture overview
> > > +---------------------
> > > +
> > > +The ARMv8.3 Pointer Authentication extension adds primitives that can be
> > > +used to mitigate certain classes of attack where an attacker can corrupt
> > > +the contents of some memory (e.g. the stack).
> > > +
> > > +The extension uses a Pointer Authentication Code (PAC) to determine
> > > +whether pointers have been modified unexpectedly. A PAC is derived from
> > > +a pointer, another value (such as the stack pointer), and a secret key
> > > +held in system registers.
> > > +
> > > +The extension adds instructions to insert a valid PAC into a pointer,
> > > +and to verify/remove the PAC from a pointer. The PAC occupies a number
> > > +of high-order bits of the pointer, which varies dependent on the
> > > +configured virtual address size and whether pointer tagging is in use.
> > > +
> > > +A subset of these instructions have been allocated from the HINT
> > > +encoding space. In the absence of the extension (or when disabled),
> > > +these instructions behave as NOPs. Applications and libraries using
> > > +these instructions operate correctly regardless of the presence of the
> > > +extension.
> >
> > Correctly, but obviously without the additional security. So I assume
> > it's expected that applications that demand this security to probe for
> > it themselves, presumably by the checking the HWCAP. Is that correct?
>
> Yes. Applications which wish to mandate pointer authentication
> (presumably using instructions outside of the HINT space) must check the
> relevant HWCAP first.
>
> [...]
>
> > > +Virtualization
> > > +--------------
> > > +
> > > +When CONFIG_ARM64_POINTER_AUTHENTICATION is selected, and uniform HW
> > > +support is present, KVM will context switch all keys used by vCPUs.
> > > +Otherwise, the feature is disabled. When disabled, accesses to keys, or
> > > +use of instructions enabled within the guest will trap to EL2, and an
> > > +UNDEFINED exception will be injected into the guest.
> >
> > If host applications will just run, with the instructions behaving like
> > NOPs, when the extension is either not present or not enabled, then
> > shouldn't guest applications also just run?
>
> The enabled/disabled wording is probably the confusing bit here.
>
> At EL1 we have conditional enables for instructions using
> AP{I,D}{A,B}Key, which behave as NOPs when disabled.
>
> At EL2 we have a single conditional trap for all instructions using
> pointer authentication, that traps to EL2 when instructions are not
> NOP'd by EL1.
>
> So "disabled by EL2" is actually "trapped by EL2", and "disabled by EL1"
> is "NOP'd by EL1".
>
> > I.e. instead of injecting UNDEF, just treat the instructions as NOPs.
> > Or did I misunderstand the trapping?
>
> I think the documentation explained it poorly. Did the above help?
Yes, both the above and the below have helped me understand. Thanks for
the clarification!
drew
>
> > Does use of the instructions at EL0 trap to EL1 or EL2?
>
> If disabled by EL1, the instructions behave as NOPs (regardless of the
> EL2 traps).
>
> If enabled by EL1, but trapped by EL2, the instructions trap to EL2.
>
> If enabled by EL1, and not trapped by EL2, the instructions work as
> usual.
>
> I'll see if I can document this better.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
From: Michal Hocko @ 2017-12-04 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204124230.GA10599@samekh>
On Mon 04-12-17 12:42:31, Andrea Reale wrote:
> On Mon 4 Dec 2017, 13:32, Michal Hocko wrote:
> > On Mon 04-12-17 11:49:09, Andrea Reale wrote:
> > > On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> > > > On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > > > > When hot-removing memory we need to free vmemmap memory.
> > > > > However, depending on the memory is being removed, it might
> > > > > not be always possible to free a full vmemmap page / huge-page
> > > > > because part of it might still be used.
> > > > >
> > > > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > > > > hot-remove") introduced a workaround for x86
> > > > > hot-remove, by which partially unused areas are filled with
> > > > > the 0xFD constant. Full pages are only removed when fully
> > > > > filled by 0xFDs.
> > > > >
> > > > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > > > > the goal of using it in place of 0xFDs. For now, this will be used for
> > > > > the arm64 port of memory hot remove, but the idea is to eventually use
> > > > > the same mechanism for x86 as well.
> > > >
> > > > Why cannot you use the same approach as x86 have? Have a look at the
> > > > vmemmap_free at al.
> > > >
> > >
> > > This arm64 hot-remove version (including vmemmap_free) is indeed an
> > > almost 1-to-1 port of the x86 approach.
> > >
> > > If you look at the first version of the patchset we submitted a while
> > > ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
> > > x86 approach of filling unsued page structs with 0xFDs. Commenting on
> > > that, Mark suggested (and, indeed, I agree with him) that relying on a
> > > magic constant for marking some portions of physical memory was quite
> > > ugly. That is why we have used memblock for the purpose in this revised
> > > patchset.
> > >
> > > If you have a different view and any concrete suggestion on how to
> > > improve this, it is definitely very well welcome.
> >
> > I would really prefer if those archictectues shared the code (and
> > concept) as much as possible. It is really a PITA to wrap your head
> > around each architectures for reasons which are not inherent to that
> > specific architecture. If you find the way how x86 is implemented ugly,
> > then all right, but making arm64 special just for the matter of taste is
> > far from ideal IMHO.
>
> The plan is indeed to use this memblock flag in x86 hot remove as well,
> in place of the 0xFDs. The change is quite straightforward and we could
> push it in a next patchset release. Our rationale was to first use it in
> the new architecture and then, once proven stable, back port it to x86.
>
> However, I am not in principle against of pushing it right now.
So please start with a simpler (cleanup) patch for x86. It will make the
life so much easier.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device
From: Andrea Reale @ 2017-12-04 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204123355.4tam7pfv34zmwzyu@dhcp22.suse.cz>
On Mon 4 Dec 2017, 13:33, Michal Hocko wrote:
> On Mon 04-12-17 11:51:29, Andrea Reale wrote:
> > On Thu 30 Nov 2017, 15:49, Michal Hocko wrote:
> > > On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> > > > Adding a "remove" sysfs handle that can be used to trigger
> > > > memory hotremove manually, exactly simmetrically with
> > > > what happens with the "probe" device for hot-add.
> > > >
> > > > This is usueful for architecture that do not rely on
> > > > ACPI for memory hot-remove.
> > >
> > > As already said elsewhere, this really has to check the online status of
> > > the range and fail some is still online.
> > >
> >
> > This is actually still done in remove_memory() (patch 2/5) with
> > walk_memory_range. We just return an error rather than BUGing().
> >
> > Or are you referring to something else?
>
> But you are not returning that error to the caller, are you?
>
> [...]
Oh, I see your point. Yes, indeed we should have returned it. Thanks for
catching the issue.
> > > > + nid = memory_add_physaddr_to_nid(phys_addr);
> > > > + ret = lock_device_hotplug_sysfs();
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + remove_memory(nid, phys_addr,
> > > > + MIN_MEMORY_BLOCK_SIZE * sections_per_block);
> > > > + unlock_device_hotplug();
> > > > + return count;
Thanks,
Andrea
>
> --
> Michal Hocko
> SUSE Labs
>
^ permalink raw reply
* [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
From: Andrea Reale @ 2017-12-04 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204123244.vfm6znonfqt6fien@dhcp22.suse.cz>
On Mon 4 Dec 2017, 13:32, Michal Hocko wrote:
> On Mon 04-12-17 11:49:09, Andrea Reale wrote:
> > On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> > > On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > > > When hot-removing memory we need to free vmemmap memory.
> > > > However, depending on the memory is being removed, it might
> > > > not be always possible to free a full vmemmap page / huge-page
> > > > because part of it might still be used.
> > > >
> > > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > > > hot-remove") introduced a workaround for x86
> > > > hot-remove, by which partially unused areas are filled with
> > > > the 0xFD constant. Full pages are only removed when fully
> > > > filled by 0xFDs.
> > > >
> > > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > > > the goal of using it in place of 0xFDs. For now, this will be used for
> > > > the arm64 port of memory hot remove, but the idea is to eventually use
> > > > the same mechanism for x86 as well.
> > >
> > > Why cannot you use the same approach as x86 have? Have a look at the
> > > vmemmap_free at al.
> > >
> >
> > This arm64 hot-remove version (including vmemmap_free) is indeed an
> > almost 1-to-1 port of the x86 approach.
> >
> > If you look at the first version of the patchset we submitted a while
> > ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
> > x86 approach of filling unsued page structs with 0xFDs. Commenting on
> > that, Mark suggested (and, indeed, I agree with him) that relying on a
> > magic constant for marking some portions of physical memory was quite
> > ugly. That is why we have used memblock for the purpose in this revised
> > patchset.
> >
> > If you have a different view and any concrete suggestion on how to
> > improve this, it is definitely very well welcome.
>
> I would really prefer if those archictectues shared the code (and
> concept) as much as possible. It is really a PITA to wrap your head
> around each architectures for reasons which are not inherent to that
> specific architecture. If you find the way how x86 is implemented ugly,
> then all right, but making arm64 special just for the matter of taste is
> far from ideal IMHO.
The plan is indeed to use this memblock flag in x86 hot remove as well,
in place of the 0xFDs. The change is quite straightforward and we could
push it in a next patchset release. Our rationale was to first use it in
the new architecture and then, once proven stable, back port it to x86.
However, I am not in principle against of pushing it right now.
Thanks,
Andrea
> --
> Michal Hocko
> SUSE Labs
>
^ permalink raw reply
* [patch v13 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Philippe Ombredanne @ 2017-12-04 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512382405-14774-3-git-send-email-oleksandrs@mellanox.com>
Oleksandr,
On Mon, Dec 4, 2017 at 11:13 AM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
[...]
> v12->v13
> Comments pointed by Philippe Ombredanne <pombredanne@nexb.com>
> - Change jtag-aspeed.c licence type to
> SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> and reorder line with license in description
[...]
> diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
> new file mode 100644
> index 0000000..2ff46b0
> --- /dev/null
> +++ b/drivers/jtag/jtag-aspeed.c
> @@ -0,0 +1,784 @@
> +/* SPDX-License-Identifier: GPL-2.0
Sorry to nit pick on this but the comment style should be // here IMHO
This is what Linus requested, e.g.:
> +// SPDX-License-Identifier: GPL-2.0
For reference, the doc is being written:Thomas (tglx) has already
submitted a first series of doc patches a few weeks ago. And AFAIK he
might be working on posting the updates soon, whenever his real time
clock yields a few cycles away from real time coding work ;)
See also these discussions with Linus [1][2][3], Thomas[4] and Greg[5]
on this and mostly related topics, where you will see Linus rationale
for the C++ comment stylle
[1] https://lkml.org/lkml/2017/11/2/715
[2] https://lkml.org/lkml/2017/11/25/125
[3] https://lkml.org/lkml/2017/11/25/133
[4] https://lkml.org/lkml/2017/11/2/805
[5] https://lkml.org/lkml/2017/10/19/165
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCHv2 12/12] arm64: docs: document pointer authentication
From: Mark Rutland @ 2017-12-04 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128150726.xui5i23uigvfo52w@kamzik.brq.redhat.com>
On Tue, Nov 28, 2017 at 04:07:26PM +0100, Andrew Jones wrote:
> Hi Mark,
Hi Drew,
> On Mon, Nov 27, 2017 at 04:38:06PM +0000, Mark Rutland wrote:
> > +Architecture overview
> > +---------------------
> > +
> > +The ARMv8.3 Pointer Authentication extension adds primitives that can be
> > +used to mitigate certain classes of attack where an attacker can corrupt
> > +the contents of some memory (e.g. the stack).
> > +
> > +The extension uses a Pointer Authentication Code (PAC) to determine
> > +whether pointers have been modified unexpectedly. A PAC is derived from
> > +a pointer, another value (such as the stack pointer), and a secret key
> > +held in system registers.
> > +
> > +The extension adds instructions to insert a valid PAC into a pointer,
> > +and to verify/remove the PAC from a pointer. The PAC occupies a number
> > +of high-order bits of the pointer, which varies dependent on the
> > +configured virtual address size and whether pointer tagging is in use.
> > +
> > +A subset of these instructions have been allocated from the HINT
> > +encoding space. In the absence of the extension (or when disabled),
> > +these instructions behave as NOPs. Applications and libraries using
> > +these instructions operate correctly regardless of the presence of the
> > +extension.
>
> Correctly, but obviously without the additional security. So I assume
> it's expected that applications that demand this security to probe for
> it themselves, presumably by the checking the HWCAP. Is that correct?
Yes. Applications which wish to mandate pointer authentication
(presumably using instructions outside of the HINT space) must check the
relevant HWCAP first.
[...]
> > +Virtualization
> > +--------------
> > +
> > +When CONFIG_ARM64_POINTER_AUTHENTICATION is selected, and uniform HW
> > +support is present, KVM will context switch all keys used by vCPUs.
> > +Otherwise, the feature is disabled. When disabled, accesses to keys, or
> > +use of instructions enabled within the guest will trap to EL2, and an
> > +UNDEFINED exception will be injected into the guest.
>
> If host applications will just run, with the instructions behaving like
> NOPs, when the extension is either not present or not enabled, then
> shouldn't guest applications also just run?
The enabled/disabled wording is probably the confusing bit here.
At EL1 we have conditional enables for instructions using
AP{I,D}{A,B}Key, which behave as NOPs when disabled.
At EL2 we have a single conditional trap for all instructions using
pointer authentication, that traps to EL2 when instructions are not
NOP'd by EL1.
So "disabled by EL2" is actually "trapped by EL2", and "disabled by EL1"
is "NOP'd by EL1".
> I.e. instead of injecting UNDEF, just treat the instructions as NOPs.
> Or did I misunderstand the trapping?
I think the documentation explained it poorly. Did the above help?
> Does use of the instructions at EL0 trap to EL1 or EL2?
If disabled by EL1, the instructions behave as NOPs (regardless of the
EL2 traps).
If enabled by EL1, but trapped by EL2, the instructions trap to EL2.
If enabled by EL1, and not trapped by EL2, the instructions work as
usual.
I'll see if I can document this better.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device
From: Michal Hocko @ 2017-12-04 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204115129.GD6373@samekh>
On Mon 04-12-17 11:51:29, Andrea Reale wrote:
> On Thu 30 Nov 2017, 15:49, Michal Hocko wrote:
> > On Thu 23-11-17 11:14:52, Andrea Reale wrote:
> > > Adding a "remove" sysfs handle that can be used to trigger
> > > memory hotremove manually, exactly simmetrically with
> > > what happens with the "probe" device for hot-add.
> > >
> > > This is usueful for architecture that do not rely on
> > > ACPI for memory hot-remove.
> >
> > As already said elsewhere, this really has to check the online status of
> > the range and fail some is still online.
> >
>
> This is actually still done in remove_memory() (patch 2/5) with
> walk_memory_range. We just return an error rather than BUGing().
>
> Or are you referring to something else?
But you are not returning that error to the caller, are you?
[...]
> > > + nid = memory_add_physaddr_to_nid(phys_addr);
> > > + ret = lock_device_hotplug_sysfs();
> > > + if (ret)
> > > + return ret;
> > > +
> > > + remove_memory(nid, phys_addr,
> > > + MIN_MEMORY_BLOCK_SIZE * sections_per_block);
> > > + unlock_device_hotplug();
> > > + return count;
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2 3/5] mm: memory_hotplug: memblock to track partially removed vmemmap mem
From: Michal Hocko @ 2017-12-04 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204114908.GC6373@samekh>
On Mon 04-12-17 11:49:09, Andrea Reale wrote:
> On Thu 30 Nov 2017, 15:51, Michal Hocko wrote:
> > On Thu 23-11-17 11:14:38, Andrea Reale wrote:
> > > When hot-removing memory we need to free vmemmap memory.
> > > However, depending on the memory is being removed, it might
> > > not be always possible to free a full vmemmap page / huge-page
> > > because part of it might still be used.
> > >
> > > Commit ae9aae9eda2d ("memory-hotplug: common APIs to support page tables
> > > hot-remove") introduced a workaround for x86
> > > hot-remove, by which partially unused areas are filled with
> > > the 0xFD constant. Full pages are only removed when fully
> > > filled by 0xFDs.
> > >
> > > This commit introduces a MEMBLOCK_UNUSED_VMEMMAP memblock flag, with
> > > the goal of using it in place of 0xFDs. For now, this will be used for
> > > the arm64 port of memory hot remove, but the idea is to eventually use
> > > the same mechanism for x86 as well.
> >
> > Why cannot you use the same approach as x86 have? Have a look at the
> > vmemmap_free at al.
> >
>
> This arm64 hot-remove version (including vmemmap_free) is indeed an
> almost 1-to-1 port of the x86 approach.
>
> If you look at the first version of the patchset we submitted a while
> ago (https://lkml.org/lkml/2017/4/11/540), we were initially using the
> x86 approach of filling unsued page structs with 0xFDs. Commenting on
> that, Mark suggested (and, indeed, I agree with him) that relying on a
> magic constant for marking some portions of physical memory was quite
> ugly. That is why we have used memblock for the purpose in this revised
> patchset.
>
> If you have a different view and any concrete suggestion on how to
> improve this, it is definitely very well welcome.
I would really prefer if those archictectues shared the code (and
concept) as much as possible. It is really a PITA to wrap your head
around each architectures for reasons which are not inherent to that
specific architecture. If you find the way how x86 is implemented ugly,
then all right, but making arm64 special just for the matter of taste is
far from ideal IMHO.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2 19/19] DO NOT MERGE
From: Ard Biesheuvel @ 2017-12-04 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204122645.31535-1-ard.biesheuvel@linaro.org>
Test code to force a kernel_neon_end+begin sequence at every yield point,
and wipe the entire NEON state before resuming the algorithm.
---
arch/arm64/include/asm/assembler.h | 33 ++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 917b026d3e00..dfee20246592 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -549,6 +549,7 @@ alternative_else_nop_endif
cmp w1, #1 // == PREEMPT_OFFSET
csel x0, x0, xzr, eq
tbnz x0, #TIF_NEED_RESCHED, 5555f // needs rescheduling?
+ b 5555f
4444:
#endif
.subsection 1
@@ -558,6 +559,38 @@ alternative_else_nop_endif
.macro yield_neon_post, lbl:req
bl kernel_neon_end
bl kernel_neon_begin
+ movi v0.16b, #0x55
+ movi v1.16b, #0x55
+ movi v2.16b, #0x55
+ movi v3.16b, #0x55
+ movi v4.16b, #0x55
+ movi v5.16b, #0x55
+ movi v6.16b, #0x55
+ movi v7.16b, #0x55
+ movi v8.16b, #0x55
+ movi v9.16b, #0x55
+ movi v10.16b, #0x55
+ movi v11.16b, #0x55
+ movi v12.16b, #0x55
+ movi v13.16b, #0x55
+ movi v14.16b, #0x55
+ movi v15.16b, #0x55
+ movi v16.16b, #0x55
+ movi v17.16b, #0x55
+ movi v18.16b, #0x55
+ movi v19.16b, #0x55
+ movi v20.16b, #0x55
+ movi v21.16b, #0x55
+ movi v22.16b, #0x55
+ movi v23.16b, #0x55
+ movi v24.16b, #0x55
+ movi v25.16b, #0x55
+ movi v26.16b, #0x55
+ movi v27.16b, #0x55
+ movi v28.16b, #0x55
+ movi v29.16b, #0x55
+ movi v30.16b, #0x55
+ movi v31.16b, #0x55
b \lbl
.previous
.endm
--
2.11.0
^ permalink raw reply related
* [PATCH v2 18/19] crypto: arm64/crct10dif-ce - yield NEON every 8 blocks of input
From: Ard Biesheuvel @ 2017-12-04 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204122645.31535-1-ard.biesheuvel@linaro.org>
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 8 blocks of input.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/crct10dif-ce-core.S | 39 ++++++++++++++++++--
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif-ce-core.S b/arch/arm64/crypto/crct10dif-ce-core.S
index d5b5a8c038c8..d57067e80bae 100644
--- a/arch/arm64/crypto/crct10dif-ce-core.S
+++ b/arch/arm64/crypto/crct10dif-ce-core.S
@@ -74,13 +74,22 @@
.text
.cpu generic+crypto
- arg1_low32 .req w0
- arg2 .req x1
- arg3 .req x2
+ arg1_low32 .req w19
+ arg2 .req x20
+ arg3 .req x21
vzr .req v13
ENTRY(crc_t10dif_pmull)
+ stp x29, x30, [sp, #-176]!
+ mov x29, sp
+ stp x19, x20, [sp, #16]
+ stp x21, x22, [sp, #32]
+
+ mov arg1_low32, w0
+ mov arg2, x1
+ mov arg3, x2
+
movi vzr.16b, #0 // init zero register
// adjust the 16-bit initial_crc value, scale it to 32 bits
@@ -175,8 +184,27 @@ CPU_LE( ext v12.16b, v12.16b, v12.16b, #8 )
subs arg3, arg3, #128
// check if there is another 64B in the buffer to be able to fold
- b.ge _fold_64_B_loop
+ b.lt _fold_64_B_end
+
+ yield_neon_pre arg3, 3, 128, _fold_64_B_loop // yield every 8 blocks
+ stp q0, q1, [sp, #48]
+ stp q2, q3, [sp, #80]
+ stp q4, q5, [sp, #112]
+ stp q6, q7, [sp, #144]
+ yield_neon_post 2f
+ b _fold_64_B_loop
+
+ .subsection 1
+2: ldp q0, q1, [sp, #48]
+ ldp q2, q3, [sp, #80]
+ ldp q4, q5, [sp, #112]
+ ldp q6, q7, [sp, #144]
+ ldr q10, rk3
+ movi vzr.16b, #0 // init zero register
+ b _fold_64_B_loop
+ .previous
+_fold_64_B_end:
// at this point, the buffer pointer is pointing at the last y Bytes
// of the buffer the 64B of folded data is in 4 of the vector
// registers: v0, v1, v2, v3
@@ -304,6 +332,9 @@ _barrett:
_cleanup:
// scale the result back to 16 bits
lsr x0, x0, #16
+ ldp x19, x20, [sp, #16]
+ ldp x21, x22, [sp, #32]
+ ldp x29, x30, [sp], #176
ret
_less_than_128:
--
2.11.0
^ permalink raw reply related
* [PATCH v2 17/19] crypto: arm64/crc32-ce - yield NEON every 16 blocks of input
From: Ard Biesheuvel @ 2017-12-04 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204122645.31535-1-ard.biesheuvel@linaro.org>
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 16 blocks of input.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/crc32-ce-core.S | 55 +++++++++++++++-----
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/crypto/crc32-ce-core.S b/arch/arm64/crypto/crc32-ce-core.S
index 18f5a8442276..bca3d22fae7b 100644
--- a/arch/arm64/crypto/crc32-ce-core.S
+++ b/arch/arm64/crypto/crc32-ce-core.S
@@ -100,9 +100,9 @@
dCONSTANT .req d0
qCONSTANT .req q0
- BUF .req x0
- LEN .req x1
- CRC .req x2
+ BUF .req x19
+ LEN .req x20
+ CRC .req x21
vzr .req v9
@@ -116,13 +116,27 @@
* size_t len, uint crc32)
*/
ENTRY(crc32_pmull_le)
- adr x3, .Lcrc32_constants
+ stp x29, x30, [sp, #-112]!
+ mov x29, sp
+ stp x19, x20, [sp, #16]
+ stp x21, x22, [sp, #32]
+
+ adr x22, .Lcrc32_constants
b 0f
ENTRY(crc32c_pmull_le)
- adr x3, .Lcrc32c_constants
+ stp x29, x30, [sp, #-112]!
+ mov x29, sp
+ stp x19, x20, [sp, #16]
+ stp x21, x22, [sp, #32]
+
+ adr x22, .Lcrc32c_constants
-0: bic LEN, LEN, #15
+0: mov BUF, x0
+ mov LEN, x1
+ mov CRC, x2
+
+ bic LEN, LEN, #15
ld1 {v1.16b-v4.16b}, [BUF], #0x40
movi vzr.16b, #0
fmov dCONSTANT, CRC
@@ -131,7 +145,7 @@ ENTRY(crc32c_pmull_le)
cmp LEN, #0x40
b.lt less_64
- ldr qCONSTANT, [x3]
+ ldr qCONSTANT, [x22]
loop_64: /* 64 bytes Full cache line folding */
sub LEN, LEN, #0x40
@@ -161,10 +175,24 @@ loop_64: /* 64 bytes Full cache line folding */
eor v4.16b, v4.16b, v8.16b
cmp LEN, #0x40
- b.ge loop_64
+ b.lt less_64
+
+ yield_neon_pre LEN, 4, 64, loop_64 // yield every 16 blocks
+ stp q1, q2, [sp, #48]
+ stp q3, q4, [sp, #80]
+ yield_neon_post 2f
+ b loop_64
+
+ .subsection 1
+2: ldp q1, q2, [sp, #48]
+ ldp q3, q4, [sp, #80]
+ ldr qCONSTANT, [x22]
+ movi vzr.16b, #0
+ b loop_64
+ .previous
less_64: /* Folding cache line into 128bit */
- ldr qCONSTANT, [x3, #16]
+ ldr qCONSTANT, [x22, #16]
pmull2 v5.1q, v1.2d, vCONSTANT.2d
pmull v1.1q, v1.1d, vCONSTANT.1d
@@ -203,8 +231,8 @@ fold_64:
eor v1.16b, v1.16b, v2.16b
/* final 32-bit fold */
- ldr dCONSTANT, [x3, #32]
- ldr d3, [x3, #40]
+ ldr dCONSTANT, [x22, #32]
+ ldr d3, [x22, #40]
ext v2.16b, v1.16b, vzr.16b, #4
and v1.16b, v1.16b, v3.16b
@@ -212,7 +240,7 @@ fold_64:
eor v1.16b, v1.16b, v2.16b
/* Finish up with the bit-reversed barrett reduction 64 ==> 32 bits */
- ldr qCONSTANT, [x3, #48]
+ ldr qCONSTANT, [x22, #48]
and v2.16b, v1.16b, v3.16b
ext v2.16b, vzr.16b, v2.16b, #8
@@ -222,6 +250,9 @@ fold_64:
eor v1.16b, v1.16b, v2.16b
mov w0, v1.s[1]
+ ldp x19, x20, [sp, #16]
+ ldp x21, x22, [sp, #32]
+ ldp x29, x30, [sp], #112
ret
ENDPROC(crc32_pmull_le)
ENDPROC(crc32c_pmull_le)
--
2.11.0
^ permalink raw reply related
* [PATCH v2 16/19] crypto: arm64/aes-ghash - yield after processing fixed number of blocks
From: Ard Biesheuvel @ 2017-12-04 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204122645.31535-1-ard.biesheuvel@linaro.org>
This updates both the core GHASH as well as the AES-GCM algorithm to
yield each time after processing a fixed chunk of input. For the GCM
driver, we align with the other AES/CE block mode drivers, and use
a block size of 64 bytes. The core GHASH is much shorter, so let's
use a block size of 128 bytes for that one.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 128 ++++++++++++++------
1 file changed, 92 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index 11ebf1ae248a..fbfd4681675d 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -212,23 +212,36 @@
ushr XL.2d, XL.2d, #1
.endm
- .macro __pmull_ghash, pn
- ld1 {SHASH.2d}, [x3]
- ld1 {XL.2d}, [x1]
+ .macro __pmull_ghash, pn, yield
+ stp x29, x30, [sp, #-64]!
+ mov x29, sp
+ stp x19, x20, [sp, #16]
+ stp x21, x22, [sp, #32]
+ str x23, [sp, #48]
+
+ mov x19, x0
+ mov x20, x1
+ mov x21, x2
+ mov x22, x3
+ mov x23, x4
+
+0: ld1 {SHASH.2d}, [x22]
+ ld1 {XL.2d}, [x20]
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
eor SHASH2.16b, SHASH2.16b, SHASH.16b
__pmull_pre_\pn
/* do the head block first, if supplied */
- cbz x4, 0f
- ld1 {T1.2d}, [x4]
- b 1f
+ cbz x23, 1f
+ ld1 {T1.2d}, [x23]
+ mov x23, xzr
+ b 2f
-0: ld1 {T1.2d}, [x2], #16
- sub w0, w0, #1
+1: ld1 {T1.2d}, [x21], #16
+ sub w19, w19, #1
-1: /* multiply XL by SHASH in GF(2^128) */
+2: /* multiply XL by SHASH in GF(2^128) */
CPU_LE( rev64 T1.16b, T1.16b )
ext T2.16b, XL.16b, XL.16b, #8
@@ -250,9 +263,19 @@ CPU_LE( rev64 T1.16b, T1.16b )
eor T2.16b, T2.16b, XH.16b
eor XL.16b, XL.16b, T2.16b
- cbnz w0, 0b
+ cbz w19, 3f
- st1 {XL.2d}, [x1]
+ yield_neon_pre w19, \yield, 1, 1b
+ st1 {XL.2d}, [x20]
+ yield_neon_post 0b
+
+ b 1b
+
+3: st1 {XL.2d}, [x20]
+ ldp x19, x20, [sp, #16]
+ ldp x21, x22, [sp, #32]
+ ldr x23, [sp, #48]
+ ldp x29, x30, [sp], #64
ret
.endm
@@ -261,11 +284,11 @@ CPU_LE( rev64 T1.16b, T1.16b )
* struct ghash_key const *k, const char *head)
*/
ENTRY(pmull_ghash_update_p64)
- __pmull_ghash p64
+ __pmull_ghash p64, 5
ENDPROC(pmull_ghash_update_p64)
ENTRY(pmull_ghash_update_p8)
- __pmull_ghash p8
+ __pmull_ghash p8, 2
ENDPROC(pmull_ghash_update_p8)
KS .req v8
@@ -304,38 +327,56 @@ ENDPROC(pmull_ghash_update_p8)
.endm
.macro pmull_gcm_do_crypt, enc
- ld1 {SHASH.2d}, [x4]
- ld1 {XL.2d}, [x1]
- ldr x8, [x5, #8] // load lower counter
+ stp x29, x30, [sp, #-96]!
+ mov x29, sp
+ stp x19, x20, [sp, #16]
+ stp x21, x22, [sp, #32]
+ stp x23, x24, [sp, #48]
+ stp x25, x26, [sp, #64]
+ str x27, [sp, #80]
+
+ mov x19, x0
+ mov x20, x1
+ mov x21, x2
+ mov x22, x3
+ mov x23, x4
+ mov x24, x5
+ mov x25, x6
+ mov x26, x7
+
+ ldr x27, [x24, #8] // load lower counter
+CPU_LE( rev x27, x27 )
+
+0: ld1 {SHASH.2d}, [x23]
+ ld1 {XL.2d}, [x20]
movi MASK.16b, #0xe1
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
-CPU_LE( rev x8, x8 )
shl MASK.2d, MASK.2d, #57
eor SHASH2.16b, SHASH2.16b, SHASH.16b
.if \enc == 1
- ld1 {KS.16b}, [x7]
+ ld1 {KS.16b}, [x26]
.endif
-0: ld1 {CTR.8b}, [x5] // load upper counter
- ld1 {INP.16b}, [x3], #16
- rev x9, x8
- add x8, x8, #1
- sub w0, w0, #1
+1: ld1 {CTR.8b}, [x24] // load upper counter
+ ld1 {INP.16b}, [x22], #16
+ rev x9, x27
+ add x27, x27, #1
+ sub w19, w19, #1
ins CTR.d[1], x9 // set lower counter
.if \enc == 1
eor INP.16b, INP.16b, KS.16b // encrypt input
- st1 {INP.16b}, [x2], #16
+ st1 {INP.16b}, [x21], #16
.endif
rev64 T1.16b, INP.16b
- cmp w6, #12
- b.ge 2f // AES-192/256?
+ cmp w25, #12
+ b.ge 4f // AES-192/256?
-1: enc_round CTR, v21
+2: enc_round CTR, v21
ext T2.16b, XL.16b, XL.16b, #8
ext IN1.16b, T1.16b, T1.16b, #8
@@ -390,27 +431,42 @@ CPU_LE( rev x8, x8 )
.if \enc == 0
eor INP.16b, INP.16b, KS.16b
- st1 {INP.16b}, [x2], #16
+ st1 {INP.16b}, [x21], #16
.endif
- cbnz w0, 0b
+ cbz w19, 3f
-CPU_LE( rev x8, x8 )
- st1 {XL.2d}, [x1]
- str x8, [x5, #8] // store lower counter
+ yield_neon_pre w19, 8, 1, 1b // yield every 8 blocks
+ st1 {XL.2d}, [x20]
+ .if \enc == 1
+ st1 {KS.16b}, [x26]
+ .endif
+ yield_neon_post 0b
+ b 1b
+
+3: st1 {XL.2d}, [x20]
.if \enc == 1
- st1 {KS.16b}, [x7]
+ st1 {KS.16b}, [x26]
.endif
+CPU_LE( rev x27, x27 )
+ str x27, [x24, #8] // store lower counter
+
+ ldp x19, x20, [sp, #16]
+ ldp x21, x22, [sp, #32]
+ ldp x23, x24, [sp, #48]
+ ldp x25, x26, [sp, #64]
+ ldr x27, [sp, #80]
+ ldp x29, x30, [sp], #96
ret
-2: b.eq 3f // AES-192?
+4: b.eq 5f // AES-192?
enc_round CTR, v17
enc_round CTR, v18
-3: enc_round CTR, v19
+5: enc_round CTR, v19
enc_round CTR, v20
- b 1b
+ b 2b
.endm
/*
--
2.11.0
^ 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