aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm64 (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-03-02Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-1/+1
Pull ARM SoC fixes from Arnd Bergmann: "One more set of simple ARM platform fixes: - A boot regression on qualcomm msm8998 - Gemini display controllers got turned off by accident - incorrect reference counting in optee" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: tee: optee: add missing of_node_put after of_device_is_available arm64: dts: qcom: msm8998: Extend TZ reserved memory area ARM: dts: gemini: Re-enable display controller
2019-03-02Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds1-2/+18
Pull more crypto fixes from Herbert Xu: "This fixes a couple of issues in arm64/chacha that was introduced in 5.0" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: arm64/chacha - fix hchacha_block_neon() for big endian crypto: arm64/chacha - fix chacha_4block_xor_neon() for big endian
2019-03-01Merge tag 'qcom-fixes-for-5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into arm/fixesArnd Bergmann1-1/+1
Qualcomm ARM64 Fixes for 5.0-rc8 * Fix TZ memory area size to avoid crashes during boot * tag 'qcom-fixes-for-5.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: arm64: dts: qcom: msm8998: Extend TZ reserved memory area
2019-02-28crypto: arm64/chacha - fix hchacha_block_neon() for big endianEric Biggers1-2/+2
On big endian arm64 kernels, the xchacha20-neon and xchacha12-neon self-tests fail because hchacha_block_neon() outputs little endian words but the C code expects native endianness. Fix it to output the words in native endianness (which also makes it match the arm32 version). Fixes: cc7cf991e9eb ("crypto: arm64/chacha20 - add XChaCha20 support") Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-02-28crypto: arm64/chacha - fix chacha_4block_xor_neon() for big endianEric Biggers1-0/+16
The change to encrypt a fifth ChaCha block using scalar instructions caused the chacha20-neon, xchacha20-neon, and xchacha12-neon self-tests to start failing on big endian arm64 kernels. The bug is that the keystream block produced in 32-bit scalar registers is directly XOR'd with the data words, which are loaded and stored in native endianness. Thus in big endian mode the data bytes end up XOR'd with the wrong bytes. Fix it by byte-swapping the keystream words in big endian mode. Fixes: 2fe55987b262 ("crypto: arm64/chacha - use combined SIMD/ALU routine for more speed") Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-02-26arm64: dts: qcom: msm8998: Extend TZ reserved memory areaMarc Gonzalez1-1/+1
My console locks up as soon as Linux writes to [88800000,88f00000[ AFAIU, that memory area is reserved for trustzone. Extend TZ reserved memory range, to prevent Linux from stepping on trustzone's toes. Cc: stable@vger.kernel.org # 4.20+ Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Fixes: c7833949564ec ("arm64: dts: qcom: msm8998: Add smem related nodes") Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-02-22Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds1-1/+1
Pull ARM SoC fixes from Arnd Bergmann: "Only a handful of device tree fixes, all simple enough: NVIDIA Tegra: - Fix a regression for booting on chromebooks TI OMAP: - Two fixes PHY mode on am335x reference boards Marvell mvebu: - A regression fix for Armada XP NAND flash controllers - An incorrect reset signal on the clearfog board" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: tegra: Restore DT ABI on Tegra124 Chromebooks ARM: dts: am335x-evm: Fix PHY mode for ethernet ARM: dts: am335x-evmsk: Fix PHY mode for ethernet arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal ARM: dts: armada-xp: fix Armada XP boards NAND description
2019-02-22Merge tag 'mvebu-fixes-5.0-2' of git://git.infradead.org/linux-mvebu into arm/fixesArnd Bergmann1-1/+1
mvebu fixes for 5.0 (part 2) Fix PHY reset signal on clearfog gt 8K (Armada 8040 based) Fix NAND description on Armada XP boards which was broken since a few release * tag 'mvebu-fixes-5.0-2' of git://git.infradead.org/linux-mvebu: arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signal ARM: dts: armada-xp: fix Armada XP boards NAND description Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-21Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds3-9/+13
Pull late arm64 fixes from Will Deacon: "Three small arm64 fixes for 5.0. They fix a build breakage with clang introduced in 4.20, an oversight in our sigframe restoration relating to the SSBS bit and a boot fix for systems with newer revisions of our interrupt controller. Summary: - Fix handling of PSTATE.SSBS bit in sigreturn() - Fix version checking of the GIC during early boot - Fix clang builds failing due to use of NEON in the crypto code" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Relax GIC version check during early boot arm64/neon: Disable -Wincompatible-pointer-types when building with Clang arm64: fix SSBS sanitization
2019-02-21kasan: fix random seed generation for tag-based modeAndrey Konovalov2-2/+3
There are two issues with assigning random percpu seeds right now: 1. We use for_each_possible_cpu() to iterate over cpus, but cpumask is not set up yet at the moment of kasan_init(), and thus we only set the seed for cpu #0. 2. A call to get_random_u32() always returns the same number and produces a message in dmesg, since the random subsystem is not yet initialized. Fix 1 by calling kasan_init_tags() after cpumask is set up. Fix 2 by using get_cycles() instead of get_random_u32(). This gives us lower quality random numbers, but it's good enough, as KASAN is meant to be used as a debugging tool and not a mitigation. Link: http://lkml.kernel.org/r/1f815cc914b61f3516ed4cc9bfd9eeca9bd5d9de.1550677973.git.andreyknvl@google.com Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-02-20arm64: Relax GIC version check during early bootVladimir Murzin1-2/+1
Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values other than 0 or 1. At the moment, Linux is quite strict in the way it handles this field at early boot stage (cpufeature is fine) and will refuse to use the system register CPU interface if it doesn't find the value 1. Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3: Initial support for GICv3") Reported-by: Chase Conklin <Chase.Conklin@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-19arm64: dts: clearfog-gt-8k: fix SGMII PHY reset signalBaruch Siach1-1/+1
The PHY reset signal goes to mpp43 on CP0. Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal") Reported-by: Denis Odintsov <oversun@me.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2019-02-18arm64/neon: Disable -Wincompatible-pointer-types when building with ClangNathan Chancellor1-0/+4
After commit cc9f8349cb33 ("arm64: crypto: add NEON accelerated XOR implementation"), Clang builds for arm64 started failing with the following error message. arch/arm64/lib/xor-neon.c:58:28: error: incompatible pointer types assigning to 'const unsigned long *' from 'uint64_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types] v3 = veorq_u64(vld1q_u64(dp1 + 6), vld1q_u64(dp2 + 6)); ^~~~~~~~ /usr/lib/llvm-9/lib/clang/9.0.0/include/arm_neon.h:7538:47: note: expanded from macro 'vld1q_u64' __ret = (uint64x2_t) __builtin_neon_vld1q_v(__p0, 51); \ ^~~~ There has been quite a bit of debate and triage that has gone into figuring out what the proper fix is, viewable at the link below, which is still ongoing. Ard suggested disabling this warning with Clang with a pragma so no neon code will have this type of error. While this is not at all an ideal solution, this build error is the only thing preventing KernelCI from having successful arm64 defconfig and allmodconfig builds on linux-next. Getting continuous integration running is more important so new warnings/errors or boot failures can be caught and fixed quickly. Link: https://github.com/ClangBuiltLinux/linux/issues/283 Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-18arm64: fix SSBS sanitizationMark Rutland1-7/+8
In valid_user_regs() we treat SSBS as a RES0 bit, and consequently it is unexpectedly cleared when we restore a sigframe or fiddle with GPRs via ptrace. This patch fixes valid_user_regs() to account for this, updating the function to refer to the latest ARM ARM (ARM DDI 0487D.a). For AArch32 tasks, SSBS appears in bit 23 of SPSR_EL1, matching its position in the AArch32-native PSR format, and we don't need to translate it as we have to for DIT. There are no other bit assignments that we need to account for today. As the recent documentation describes the DIT bit, we can drop our comment regarding DIT. While removing SSBS from the RES0 masks, existing inconsistent whitespace is corrected. Fixes: d71be2b6c0e19180 ("arm64: cpufeature: Detect SSBS and advertise to userspace") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-17Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds2-1/+11
Pull EFI fixes from Ingo Molnar: "This tree reverts a GICv3 commit (which was broken) and fixes it in another way, by adding a memblock build-time entries quirk for ARM64" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/arm: Revert "Defer persistent reservations until after paging_init()" arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve table
2019-02-17Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds5-20/+101
Pull KVM fixes from Paolo Bonzini: "A somewhat bigger ARM update, and the usual smattering of x86 bug fixes" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: vmx: Fix entry number check for add_atomic_switch_msr() KVM: x86: Recompute PID.ON when clearing PID.SN KVM: nVMX: Restore a preemption timer consistency check x86/kvm/nVMX: read from MSR_IA32_VMX_PROCBASED_CTLS2 only when it is available KVM: arm64: Forbid kprobing of the VHE world-switch code KVM: arm64: Relax the restriction on using stage2 PUD huge mapping arm: KVM: Add missing kvm_stage2_has_pmd() helper KVM: arm/arm64: vgic: Always initialize the group of private IRQs arm/arm64: KVM: Don't panic on failure to properly reset system registers arm/arm64: KVM: Allow a VCPU to fully reset itself KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loaded arm64: KVM: Don't generate UNDEF when LORegion feature is present KVM: arm/arm64: vgic: Make vgic_cpu->ap_list_lock a raw_spinlock KVM: arm/arm64: vgic: Make vgic_dist->lpi_list_lock a raw_spinlock KVM: arm/arm64: vgic: Make vgic_irq->irq_lock a raw_spinlock
2019-02-16efi/arm: Revert "Defer persistent reservations until after paging_init()"Ard Biesheuvel1-1/+0
This reverts commit eff896288872d687d9662000ec9ae11b6d61766f, which deferred the processing of persistent memory reservations to a point where the memory may have already been allocated and overwritten, defeating the purpose. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190215123333.21209-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-16arm64, mm, efi: Account for GICv3 LPI tables in static memblock reserve tableArd Biesheuvel1-0/+11
In the irqchip and EFI code, we have what basically amounts to a quirk to work around a peculiarity in the GICv3 architecture, which permits the system memory address of LPI tables to be programmable only once after a CPU reset. This means kexec kernels must use the same memory as the first kernel, and thus ensure that this memory has not been given out for other purposes by the time the ITS init code runs, which is not very early for secondary CPUs. On systems with many CPUs, these reservations could overflow the memblock reservation table, and this was addressed in commit: eff896288872 ("efi/arm: Defer persistent reservations until after paging_init()") However, this turns out to have made things worse, since the allocation of page tables and heap space for the resized memblock reservation table itself may overwrite the regions we are attempting to reserve, which may cause all kinds of corruption, also considering that the ITS will still be poking bits into that memory in response to incoming MSIs. So instead, let's grow the static memblock reservation table on such systems so it can accommodate these reservations at an earlier time. This will permit us to revert the above commit in a subsequent patch. [ mingo: Minor cleanups. ] Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190215123333.21209-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-15Merge tag 'imx-fixes-5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixesArnd Bergmann2-22/+24
i.MX fixes for 5.0, 3rd round: It contains a fix for i.MX8MQ EVK board device tree, which makes the broken eMMC support work as expected. * tag 'imx-fixes-5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: arm64: dts: imx8mq: Fix boot from eMMC
2019-02-15Merge tag 'v5.0-rockchip-dts64fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixesArnd Bergmann4-3/+5
Fix for new dtc graph warnings and a regulator fix for rock64. * tag 'v5.0-rockchip-dts64fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64 arm64: dts: rockchip: fix graph_port warning on rk3399 bob kevin and excavator
2019-02-13Merge tag 'kvm-arm-fixes-for-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-masterPaolo Bonzini5-20/+101
KVM/ARM fixes for 5.0: - Fix the way we reset vcpus, plugging the race that could happen on VHE - Fix potentially inconsistent group setting for private interrupts - Don't generate UNDEF when LORegion feature is present - Relax the restriction on using stage2 PUD huge mapping - Turn some spinlocks into raw_spinlocks to help RT compliance
2019-02-08Merge tag 'armsoc-fixes-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds20-30/+26
Pull ARM SoC fixes from Arnd Bergmann: "This is a bit larger than normal, as we had not managed to send out a pull request before traveling for a week without my signing key. There are multiple code fixes for older bugs, all of which should get backported into stable kernels: - tango: one fix for multiplatform configurations broken on other platforms when tango is enabled - arm_scmi: device unregistration fix - iop32x: fix kernel oops from extraneous __init annotation - pxa: remove a double kfree - fsl qbman: close an interrupt clearing race The rest is the usual collection of smaller fixes for device tree files, on the renesas, allwinner, meson, omap, davinci, qualcomm and imx platforms. Some of these are for compile-time warnings, most are for board specific functionality that fails to work because of incorrect settings" * tag 'armsoc-fixes-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (30 commits) ARM: tango: Improve ARCH_MULTIPLATFORM compatibility firmware: arm_scmi: provide the mandatory device release callback ARM: iop32x/n2100: fix PCI IRQ mapping arm64: dts: add msm8996 compatible to gicv3 ARM: dts: am335x-shc.dts: fix wrong cd pin level ARM: dts: n900: fix mmc1 card detect gpio polarity ARM: dts: omap3-gta04: Fix graph_port warning ARM: pxa: ssp: unneeded to free devm_ allocated data ARM: dts: r8a7743: Convert to new LVDS DT bindings soc: fsl: qbman: avoid race in clearing QMan interrupt arm64: dts: renesas: r8a77965: Enable DMA for SCIF2 arm64: dts: renesas: r8a7796: Enable DMA for SCIF2 arm64: dts: renesas: r8a774a1: Enable DMA for SCIF2 ARM: dts: da850: fix interrupt numbers for clocksource dt-bindings: imx8mq: Number clocks consecutively arm64: dts: meson: Fix mmc cd-gpios polarity ARM: dts: imx6sx: correct backward compatible of gpt ARM: dts: imx: replace gpio-key,wakeup with wakeup-source property ARM: dts: vf610-bk4: fix incorrect #address-cells for dspi3 ARM: dts: meson8m2: mxiii-plus: mark the SD card detection GPIO active-low ...
2019-02-07KVM: arm64: Forbid kprobing of the VHE world-switch codeJames Morse2-0/+10
On systems with VHE the kernel and KVM's world-switch code run at the same exception level. Code that is only used on a VHE system does not need to be annotated as __hyp_text as it can reside anywhere in the kernel text. __hyp_text was also used to prevent kprobes from patching breakpoint instructions into this region, as this code runs at a different exception level. While this is no longer true with VHE, KVM still switches VBAR_EL1, meaning a kprobe's breakpoint executed in the world-switch code will cause a hyp-panic. echo "p:weasel sysreg_save_guest_state_vhe" > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/weasel/enable lkvm run -k /boot/Image --console serial -p "console=ttyS0 earlycon=uart,mmio,0x3f8" # lkvm run -k /boot/Image -m 384 -c 3 --name guest-1474 Info: Placing fdt at 0x8fe00000 - 0x8fffffff Info: virtio-mmio.devices=0x200@0x10000:36 Info: virtio-mmio.devices=0x200@0x10200:37 Info: virtio-mmio.devices=0x200@0x10400:38 [ 614.178186] Kernel panic - not syncing: HYP panic: [ 614.178186] PS:404003c9 PC:ffff0000100d70e0 ESR:f2000004 [ 614.178186] FAR:0000000080080000 HPFAR:0000000000800800 PAR:1d00007edbadc0de [ 614.178186] VCPU:00000000f8de32f1 [ 614.178383] CPU: 2 PID: 1482 Comm: kvm-vcpu-0 Not tainted 5.0.0-rc2 #10799 [ 614.178446] Call trace: [ 614.178480] dump_backtrace+0x0/0x148 [ 614.178567] show_stack+0x24/0x30 [ 614.178658] dump_stack+0x90/0xb4 [ 614.178710] panic+0x13c/0x2d8 [ 614.178793] hyp_panic+0xac/0xd8 [ 614.178880] kvm_vcpu_run_vhe+0x9c/0xe0 [ 614.178958] kvm_arch_vcpu_ioctl_run+0x454/0x798 [ 614.179038] kvm_vcpu_ioctl+0x360/0x898 [ 614.179087] do_vfs_ioctl+0xc4/0x858 [ 614.179174] ksys_ioctl+0x84/0xb8 [ 614.179261] __arm64_sys_ioctl+0x28/0x38 [ 614.179348] el0_svc_common+0x94/0x108 [ 614.179401] el0_svc_handler+0x38/0x78 [ 614.179487] el0_svc+0x8/0xc [ 614.179558] SMP: stopping secondary CPUs [ 614.179661] Kernel Offset: disabled [ 614.179695] CPU features: 0x003,2a80aa38 [ 614.179758] Memory Limit: none [ 614.179858] ---[ end Kernel panic - not syncing: HYP panic: [ 614.179858] PS:404003c9 PC:ffff0000100d70e0 ESR:f2000004 [ 614.179858] FAR:0000000080080000 HPFAR:0000000000800800 PAR:1d00007edbadc0de [ 614.179858] VCPU:00000000f8de32f1 ]--- Annotate the VHE world-switch functions that aren't marked __hyp_text using NOKPROBE_SYMBOL(). Signed-off-by: James Morse <james.morse@arm.com> Fixes: 3f5c90b890ac ("KVM: arm64: Introduce VHE-specific kvm_vcpu_run") Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-07arm/arm64: KVM: Don't panic on failure to properly reset system registersMarc Zyngier1-3/+5
Failing to properly reset system registers is pretty bad. But not quite as bad as bringing the whole machine down... So warn loudly, but slightly more gracefully. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com>
2019-02-07arm/arm64: KVM: Allow a VCPU to fully reset itselfMarc Zyngier2-0/+35
The current kvm_psci_vcpu_on implementation will directly try to manipulate the state of the VCPU to reset it. However, since this is not done on the thread that runs the VCPU, we can end up in a strangely corrupted state when the source and target VCPUs are running at the same time. Fix this by factoring out all reset logic from the PSCI implementation and forwarding the required information along with a request to the target VCPU. Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
2019-02-07KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loadedChristoffer Dall1-2/+24
We have two ways to reset a vcpu: - either through VCPU_INIT - or through a PSCI_ON call The first one is easy to reason about. The second one is implemented in a more bizarre way, as it is the vcpu that handles PSCI_ON that resets the vcpu that is being powered-on. As we need to turn the logic around and have the target vcpu to reset itself, we must take some preliminary steps. Resetting the VCPU state modifies the system register state in memory, but this may interact with vcpu_load/vcpu_put if running with preemption disabled, which in turn may lead to corrupted system register state. Address this by disabling preemption and doing put/load if required around the reset logic. Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-02-05arm64: kexec_file: handle empty command-lineJean-Philippe Brucker1-1/+3
Calling strlen() on cmdline == NULL produces a kernel oops. Since having a NULL cmdline is valid, handle this case explicitly. Fixes: 52b2a8af7436 ("arm64: kexec_file: load initrd and device-tree") Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-04arm64: ptdump: Don't iterate kernel page tables using PTRS_PER_PXXWill Deacon1-30/+29
When 52-bit virtual addressing is enabled for userspace (CONFIG_ARM64_USER_VA_BITS_52=y), the kernel continues to utilise 48-bit virtual addressing in TTBR1. Consequently, PTRS_PER_PGD reflects the larger page table size for userspace and the pgd pointer for kernel page tables is offset before being written to TTBR1. This means that we can't use PTRS_PER_PGD to iterate over kernel page tables unless we apply the same offset, which is fiddly to get right and leads to some non-idiomatic walking code. Instead, just follow the usual pattern when walking page tables by using a while loop driven by pXd_offset() and pXd_addr_end(). Reported-by: Qian Cai <cai@lca.pw> Tested-by: Qian Cai <cai@lca.pw> Acked-by: Steve Capper <steve.capper@arm.com> Tested-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: hibernate: Clean the __hyp_text to PoC after resumeJames Morse1-1/+3
During resume hibernate restores all physical memory. Any memory that is accessed with the MMU disabled needs to be cleaned to the PoC. KVMs __hyp_text was previously ommitted as it runs with the MMU enabled, but now that the hyp-stub is located in this section, we must clean __hyp_text too. This ensures secondary CPUs that come online after hibernate has finished resuming, and load KVM via the freshly written hyp-stub see the correct instructions. Signed-off-by: James Morse <james.morse@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: hyp-stub: Forbid kprobing of the hyp-stubJames Morse1-0/+2
The hyp-stub is loaded by the kernel's early startup code at EL2 during boot, before KVM takes ownership later. The hyp-stub's text is part of the regular kernel text, meaning it can be kprobed. A breakpoint in the hyp-stub causes the CPU to spin in el2_sync_invalid. Add it to the __hyp_text. Signed-off-by: James Morse <james.morse@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: kprobe: Always blacklist the KVM world-switch codeJames Morse1-3/+3
On systems with VHE the kernel and KVM's world-switch code run at the same exception level. Code that is only used on a VHE system does not need to be annotated as __hyp_text as it can reside anywhere in the kernel text. __hyp_text was also used to prevent kprobes from patching breakpoint instructions into this region, as this code runs at a different exception level. While this is no longer true with VHE, KVM still switches VBAR_EL1, meaning a kprobe's breakpoint executed in the world-switch code will cause a hyp-panic. Move the __hyp_text check in the kprobes blacklist so it applies on VHE systems too, to cover the common code and guest enter/exit assembly. Fixes: 888b3c8720e0 ("arm64: Treat all entry code as non-kprobe-able") Reviewed-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: kaslr: ensure randomized quantities are clean also when kaslr is offArd Biesheuvel1-0/+1
Commit 1598ecda7b23 ("arm64: kaslr: ensure randomized quantities are clean to the PoC") added cache maintenance to ensure that global variables set by the kaslr init routine are not wiped clean due to cache invalidation occurring during the second round of page table creation. However, if kaslr_early_init() exits early with no randomization being applied (either due to the lack of a seed, or because the user has disabled kaslr explicitly), no cache maintenance is performed, leading to the same issue we attempted to fix earlier, as far as the module_alloc_base variable is concerned. Note that module_alloc_base cannot be initialized statically, because that would cause it to be subject to a R_AARCH64_RELATIVE relocation, causing it to be overwritten by the second round of KASLR relocation processing. Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR") Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: Do not issue IPIs for user executable ptesCatalin Marinas1-1/+5
Commit 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") was aimed at fixing the I-cache invalidation for kernel mappings. However, it inadvertently caused all cache maintenance for user mappings via set_pte_at() -> __sync_icache_dcache() -> sync_icache_aliases() to call kick_all_cpus_sync(). Reported-by: Shijith Thotton <sthotton@marvell.com> Tested-by: Shijith Thotton <sthotton@marvell.com> Reported-by: Wandun Chen <chenwandun@huawei.com> Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings") Cc: <stable@vger.kernel.org> # 4.19.x- Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-01arm64: dts: imx8mq: Fix boot from eMMCCarlo Caione2-22/+24
The boot from eMMC is currently broken on the NXP i.MX8MQ EVK board. When trying to boot from eMMC it fails with: ... [ 1.271938] mmc1: Tuning failed, falling back to fixed sampling clock [ 1.287429] print_req_error: I/O error, dev mmcblk1, sector 1 flags 0 [ 1.306833] mmc1: Tuning failed, falling back to fixed sampling clock [ 1.322325] print_req_error: I/O error, dev mmcblk1, sector 2 flags 0 [ 1.329559] Buffer I/O error on dev mmcblk1, logical block 0, async page read [ 1.336714] mmcblk1: unable to read partition table ... The problem is the result of a partial misconfiguration of the pins and the missing assigned clock rate. Fixes: 9079aca4aacd ("arm64: add support for i.MX8M EVK board") Signed-off-by: Carlo Caione <ccaione@baylibre.com> Tested-by: Chris Spencer <christopher.spencer@sea.co.uk> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-01-30Merge tag 'sunxi-fixes-for-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/fixesArnd Bergmann2-1/+2
Allwinner Fixes for 5.0 A couple of device tree fixes for the 5.0 cycle: - Add missing clock-output-names for the osc24M clock on sun6i/A31 The Linux clock driver uses the device node as the clock name if the property is missing. The node name was changed in 5.0-rc1, breaking a subtle dependency in the sunxi-ng clock driver, and renders Linux unable to completely boot up. - Add alias for Ethernet controller on Beelink X2 This allows the bootloader to assign a deterministically generated MAC address to it. - Add property to enable USB VBUS regulator on OrangePi Win The board had defined the constraints for the regulator, but was missing the property to actually enable it. * tag 'sunxi-fixes-for-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: a64: Fix USB OTG regulator ARM: dts: sun8i: h3: Add ethernet0 alias to Beelink X2 ARM: dts: sun6i: Add clock-output-names to osc24M clock arm64: dts: allwinner: a64: Fix the video engine compatible Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-01-30Merge tag 'amlogic-fixes-2.1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/fixesArnd Bergmann14-28/+14
Amlogic fixes for v5.0-rc, round 2 - several fixups for the GPIO cd-inverted change - IRQ trigger fixes for MAC IRQ * tag 'amlogic-fixes-2.1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: meson: Fix mmc cd-gpios polarity ARM: dts: meson8m2: mxiii-plus: mark the SD card detection GPIO active-low ARM: dts: meson8b: ec100: mark the SD card detection GPIO active-low ARM: dts: meson8b: odroidc1: mark the SD card detection GPIO active-low arm: dts: meson: Fix IRQ trigger type for macirq Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-01-30Merge tag 'qcom-fixes-for-5.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into arm/fixesArnd Bergmann1-1/+1
Qualcomm ARM64 Fixes for 5.0-rc3 * Fix irq controller compatible for the MSM8996 platforms * tag 'qcom-fixes-for-5.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux: arm64: dts: add msm8996 compatible to gicv3 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-01-30Merge tag 'renesas-fixes2-for-v5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into arm/fixesArnd Bergmann3-0/+9
Second Round of Renesas ARM Based SoC Fixes for v5.0 Enable DMA for SCIF2 on R-Car M3-W (r8a7796) and M3-n (r8a77965), and (RZ/G2M) r8a774a1 SoCs. This is was omitted from patches enabling DMA for other SCIF devices on the same SoCs due to missing documentation. However, it is regarded as a fix as arguably those patches claim to add this feature. Per-SoC patches are provided to ease backporting of this fix as the kernel version to be fixed is different for each SoC. * tag 'renesas-fixes2-for-v5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: arm64: dts: renesas: r8a77965: Enable DMA for SCIF2 arm64: dts: renesas: r8a7796: Enable DMA for SCIF2 arm64: dts: renesas: r8a774a1: Enable DMA for SCIF2 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-01-27arm64: dts: rockchip: enable usb-host regulators at boot on rk3328-rock64Dmitry Voytik1-0/+2
After commit ef05bcb60c1a, boot from USB drives is broken. Fix this problem by enabling usb-host regulators during boot time. Fixes: ef05bcb60c1a ("arm64: dts: rockchip: fix vcc_host1_5v pin assign on rk3328-rock64") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Voytik <voytikd@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-01-27arm64: dts: rockchip: fix graph_port warning on rk3399 bob kevin and excavatorEnric Balletbo i Serra3-3/+3
Ports are described by child 'port' nodes contained in the device node. 'ports' is optional and is used to group all 'port' nodes which is not the case here. This patch fixes the following warnings: arch/arm64/boot/dts/rockchip/rk3399-gru-bob.dts:25.9-29.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port' arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts:46.9-50.5: Warningi (graph_port): /edp-panel/ports: graph port node name should be 'port' arch/arm64/boot/dts/rockchip/rk3399-sapphire-excavator.dts:94.9-98.5: Warning (graph_port): /edp-panel/ports: graph port node name should be 'port' Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-01-25arm64: KVM: Don't generate UNDEF when LORegion feature is presentMarc Zyngier1-15/+27
We currently hide the LORegion feature, and generate an UNDEF if the guest dares using the corresponding registers. This is a bit extreme, as ARMv8.1 guarantees the feature to be present. The guest should check the feature register before doing anything, but we could also give the guest some slack (read "allow the guest to be a bit stupid"). So instead of unconditionnaly deliver an exception, let's only do it when the host doesn't support LORegion at all (or when the feature has been sanitized out), and treat the registers as RAZ/WI otherwise (with the exception of LORID_EL1 being RO). Fixes: cc33c4e20185 ("arm64/kvm: Prohibit guest LOR accesses") Suggested-by: Richard Henderson <richard.henderson@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
2019-01-24arm64: dts: add msm8996 compatible to gicv3Srinivas Kandagatla1-1/+1
Add compatible to gicv3 node to enable quirk required to restrict writing to GICR_WAKER register which is restricted on msm8996 SoC in Hypervisor. With this quirk MSM8996 can at least boot out of mainline, which can help community to work with boards based on MSM8996. Without this patch Qualcomm DB820c board reboots on mainline. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-01-23arm64/xen: fix xen-swiotlb cache flushingChristoph Hellwig3-6/+77
Xen-swiotlb hooks into the arm/arm64 arch code through a copy of the DMA DMA mapping operations stored in the struct device arch data. Switching arm64 to use the direct calls for the merged DMA direct / swiotlb code broke this scheme. Replace the indirect calls with direct-calls in xen-swiotlb as well to fix this problem. Fixes: 356da6d0cde3 ("dma-mapping: bypass indirect calls for dma-direct") Reported-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2019-01-17arm64: dts: renesas: r8a77965: Enable DMA for SCIF2Geert Uytterhoeven1-0/+3
SCIF2 on R-Car M3-N can be used with both DMAC1 and DMAC2. Fixes: 0ea5b2fd38db56aa ("arm64: dts: renesas: r8a77965: Add SCIF device nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-01-17arm64: dts: renesas: r8a7796: Enable DMA for SCIF2Geert Uytterhoeven1-0/+3
SCIF2 on R-Car M3-W can be used with both DMAC1 and DMAC2. Fixes: dbcae5ea4bd27409 ("arm64: dts: r8a7796: Enable SCIF DMA") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-01-17arm64: dts: renesas: r8a774a1: Enable DMA for SCIF2Geert Uytterhoeven1-0/+3
SCIF2 on RZ/G2M can be used with both DMAC1 and DMAC2. Fixes: 3a3933a4fa36430a ("arm64: dts: renesas: r8a774a1: Add SCIF and HSCIF nodes") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-01-16kasan, arm64: remove redundant ARCH_SLAB_MINALIGN defineAndrey Konovalov1-2/+0
Defining ARCH_SLAB_MINALIGN in arch/arm64/include/asm/cache.h when KASAN is off is not needed, as it is defined in defined in include/linux/slab.h as ifndef. Signed-off-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-01-16arm64: kaslr: ensure randomized quantities are clean to the PoCArd Biesheuvel1-2/+6
kaslr_early_init() is called with the kernel mapped at its link time offset, and if it returns with a non-zero offset, the kernel is unmapped and remapped again at the randomized offset. During its execution, kaslr_early_init() also randomizes the base of the module region and of the linear mapping of DRAM, and sets two variables accordingly. However, since these variables are assigned with the caches on, they may get lost during the cache maintenance that occurs when unmapping and remapping the kernel, so ensure that these values are cleaned to the PoC. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR") Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-01-16arm64: kpti: Update arm64_kernel_use_ng_mappings() when forced onJames Morse1-1/+4
Since commit b89d82ef01b3 ("arm64: kpti: Avoid rewriting early page tables when KASLR is enabled"), a kernel built with CONFIG_RANDOMIZE_BASE can decide early whether to use non-global mappings by checking the kaslr_offset(). A kernel built without CONFIG_RANDOMIZE_BASE, instead checks the cpufeature static-key. This leaves a gap where CONFIG_RANDOMIZE_BASE was enabled, no kaslr seed was provided, but kpti was forced on using the cmdline option. When the decision is made late, kpti_install_ng_mappings() will re-write the page tables, but arm64_kernel_use_ng_mappings()'s value does not change as it only tests the cpufeature static-key if CONFIG_RANDOMIZE_BASE is disabled. This function influences PROT_DEFAULT via PTE_MAYBE_NG, and causes pgattr_change_is_safe() to catch nG->G transitions when the unchanged PROT_DEFAULT is used as part of PAGE_KERNEL_RO: [ 1.942255] alternatives: patching kernel code [ 1.998288] ------------[ cut here ]------------ [ 2.000693] kernel BUG at arch/arm64/mm/mmu.c:165! [ 2.019215] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 2.020257] Modules linked in: [ 2.020807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc2 #51 [ 2.021917] Hardware name: linux,dummy-virt (DT) [ 2.022790] pstate: 40000005 (nZcv daif -PAN -UAO) [ 2.023742] pc : __create_pgd_mapping+0x508/0x6d0 [ 2.024671] lr : __create_pgd_mapping+0x500/0x6d0 [ 2.058059] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____)) [ 2.059369] Call trace: [ 2.059845] __create_pgd_mapping+0x508/0x6d0 [ 2.060684] update_mapping_prot+0x48/0xd0 [ 2.061477] mark_linear_text_alias_ro+0xdc/0xe4 [ 2.070502] smp_cpus_done+0x90/0x98 [ 2.071216] smp_init+0x100/0x114 [ 2.071878] kernel_init_freeable+0xd4/0x220 [ 2.072750] kernel_init+0x10/0x100 [ 2.073455] ret_from_fork+0x10/0x18 [ 2.075414] ---[ end trace 3572f3a7782292de ]--- [ 2.076389] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b If arm64_kernel_unmapped_at_el0() is true, arm64_kernel_use_ng_mappings() should also be true. Signed-off-by: James Morse <james.morse@arm.com> CC: Ard Biesheuvel <ard.biesheuvel@linaro.org> CC: John Garry <john.garry@huawei.com> CC: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-01-14arm64: dts: meson: Fix mmc cd-gpios polarityLoys Ollivier14-28/+14
Commit 89a5e15bcba8 ("gpio/mmc/of: Respect polarity in the device tree") changed the behavior of "cd-inverted" to follow the device tree bindings specification: According to SDHCI standard, CD lines are specified as "active low". Using the "cd-inverted" property means that the CD line is "active high". Fix the SD card description for meson by setting the cd-gpios as "active low", according to the boards specifications, and dropping the "cd-inverted" property. Fixes: 89a5e15bcba8 ("gpio/mmc/of: Respect polarity in the device tree") Signed-off-by: Loys Ollivier <lollivier@baylibre.com> Signed-off-by: Kevin Hilman <khilman@baylibre.com>