On Thu, Nov 01, 2018 at 09:18:02PM -0400, David Long wrote: > On 10/31/18 9:56 AM, David Long wrote: > >From: "David A. Long" <dave.long@xxxxxxxxxx> > > > >V4.9 backport of spectre patches from Russell M. King's spectre branch. > >Patches not yet in upstream are excluded. > > > >Marc Zyngier (2): > > ARM: KVM: invalidate BTB on guest exit for Cortex-A12/A17 > > ARM: KVM: invalidate icache on guest exit for Cortex-A15 > > > >Russell King (22): > > ARM: add more CPU part numbers for Cortex and Brahma B15 CPUs > > ARM: bugs: prepare processor bug infrastructure > > ARM: bugs: hook processor bug checking into SMP and suspend paths > > ARM: bugs: add support for per-processor bug checking > > ARM: spectre: add Kconfig symbol for CPUs vulnerable to Spectre > > ARM: spectre-v2: harden branch predictor on context switches > > ARM: spectre-v2: add Cortex A8 and A15 validation of the IBE bit > > ARM: spectre-v2: harden user aborts in kernel space > > ARM: spectre-v2: add firmware based hardening > > ARM: spectre-v2: warn about incorrect context switching functions > > ARM: spectre-v2: KVM: invalidate icache on guest exit for Brahma B15 > > ARM: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling > > ARM: KVM: report support for SMCCC_ARCH_WORKAROUND_1 > > ARM: spectre-v1: add speculation barrier (csdb) macros > > ARM: spectre-v1: add array_index_mask_nospec() implementation > > ARM: spectre-v1: fix syscall entry > > ARM: signal: copy registers using __copy_from_user() > > ARM: vfp: use __copy_from_user() when restoring VFP state > > ARM: oabi-compat: copy semops using __copy_from_user() > > ARM: use __inttype() in get_user() > > ARM: spectre-v1: use get_user() for __get_user() > > ARM: spectre-v1: mitigate user accesses > > > > arch/arm/include/asm/assembler.h | 12 ++ > > arch/arm/include/asm/barrier.h | 32 ++++++ > > arch/arm/include/asm/bugs.h | 6 +- > > arch/arm/include/asm/cp15.h | 3 + > > arch/arm/include/asm/cputype.h | 8 ++ > > arch/arm/include/asm/kvm_asm.h | 2 - > > arch/arm/include/asm/kvm_host.h | 14 ++- > > arch/arm/include/asm/kvm_mmu.h | 23 +++- > > arch/arm/include/asm/proc-fns.h | 4 + > > arch/arm/include/asm/system_misc.h | 15 +++ > > arch/arm/include/asm/thread_info.h | 4 +- > > arch/arm/include/asm/uaccess.h | 26 +++-- > > arch/arm/kernel/Makefile | 1 + > > arch/arm/kernel/bugs.c | 18 +++ > > arch/arm/kernel/entry-common.S | 18 ++- > > arch/arm/kernel/entry-header.S | 25 +++++ > > arch/arm/kernel/signal.c | 55 ++++----- > > arch/arm/kernel/smp.c | 4 + > > arch/arm/kernel/suspend.c | 2 + > > arch/arm/kernel/sys_oabi-compat.c | 8 +- > > arch/arm/kvm/hyp/hyp-entry.S | 110 +++++++++++++++++- > > arch/arm/lib/copy_from_user.S | 9 ++ > > arch/arm/mm/Kconfig | 23 ++++ > > arch/arm/mm/Makefile | 2 +- > > arch/arm/mm/fault.c | 3 + > > arch/arm/mm/proc-macros.S | 3 +- > > arch/arm/mm/proc-v7-2level.S | 6 - > > arch/arm/mm/proc-v7-bugs.c | 174 +++++++++++++++++++++++++++++ > > arch/arm/mm/proc-v7.S | 154 +++++++++++++++++++------ > > arch/arm/vfp/vfpmodule.c | 17 ++- > > 30 files changed, 674 insertions(+), 107 deletions(-) > > create mode 100644 arch/arm/kernel/bugs.c > > create mode 100644 arch/arm/mm/proc-v7-bugs.c > > > > kvm-unit-test'ing of this results in a hypervisor panic that doesn't happen > without the patches. This needs to be figured out before it is accepted into > stable. Looks like a V2 will be needed. Clearly kernelci testing alone is > not sufficient when dealing with kvm changes. I've discovered in the last few days that kernelci boot testing is next to useless - it bases its pass/fail result on whether it gets to a shell prompt, which can happen even if the kernel hits a BUG() or warning that doesn't prevent the system getting to a shell prompt. For example, see: 01:08:40.181846 [ 9.309984] Unable to handle kernel paging request at virtual address e7fddef0 which is the kernel hitting a BUG() in: https://storage.kernelci.org/rmk/to-build/v4.16-38-g9fa10446d304/arm/multi_v7_defconfig/lab-collabora/boot-exynos5800-peach-pi.html and that results in a "pass" result for that boot test. So, don't believe a "pass" result from kernelci at the moment, it's meaningless in determining whether anything has broken. The only way around this is to manually read each and every boot log, which is tedious, or run your own tests on local systems. I've reported this to info@xxxxxxxxxxxx earlier this week, and am waiting for a response. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
