1. 23 Jun, 2023 4 commits
    • Catalin Marinas's avatar
      Merge branch 'for-next/feat_s1pie' into for-next/core · abc17128
      Catalin Marinas authored
      * for-next/feat_s1pie:
        : Support for the Armv8.9 Permission Indirection Extensions (stage 1 only)
        KVM: selftests: get-reg-list: add Permission Indirection registers
        KVM: selftests: get-reg-list: support ID register features
        arm64: Document boot requirements for PIE
        arm64: transfer permission indirection settings to EL2
        arm64: enable Permission Indirection Extension (PIE)
        arm64: add encodings of PIRx_ELx registers
        arm64: disable EL2 traps for PIE
        arm64: reorganise PAGE_/PROT_ macros
        arm64: add PTE_WRITE to PROT_SECT_NORMAL
        arm64: add PTE_UXN/PTE_WRITE to SWAPPER_*_FLAGS
        KVM: arm64: expose ID_AA64MMFR3_EL1 to guests
        KVM: arm64: Save/restore PIE registers
        KVM: arm64: Save/restore TCR2_EL1
        arm64: cpufeature: add Permission Indirection Extension cpucap
        arm64: cpufeature: add TCR2 cpucap
        arm64: cpufeature: add system register ID_AA64MMFR3
        arm64/sysreg: add PIR*_ELx registers
        arm64/sysreg: update HCRX_EL2 register
        arm64/sysreg: add system registers TCR2_ELx
        arm64/sysreg: Add ID register ID_AA64MMFR3
      abc17128
    • Catalin Marinas's avatar
      Merge branches 'for-next/kpti', 'for-next/missing-proto-warn',... · f42039d1
      Catalin Marinas authored
      Merge branches 'for-next/kpti', 'for-next/missing-proto-warn', 'for-next/iss2-decode', 'for-next/kselftest', 'for-next/misc', 'for-next/feat_mops', 'for-next/module-alloc', 'for-next/sysreg', 'for-next/cpucap', 'for-next/acpi', 'for-next/kdump', 'for-next/acpi-doc', 'for-next/doc' and 'for-next/tpidr2-fix', remote-tracking branch 'arm64/for-next/perf' into for-next/core
      
      * arm64/for-next/perf:
        docs: perf: Fix warning from 'make htmldocs' in hisi-pmu.rst
        docs: perf: Add new description for HiSilicon UC PMU
        drivers/perf: hisi: Add support for HiSilicon UC PMU driver
        drivers/perf: hisi: Add support for HiSilicon H60PA and PAv3 PMU driver
        perf: arm_cspmu: Add missing MODULE_DEVICE_TABLE
        perf/arm-cmn: Add sysfs identifier
        perf/arm-cmn: Revamp model detection
        perf/arm_dmc620: Add cpumask
        dt-bindings: perf: fsl-imx-ddr: Add i.MX93 compatible
        drivers/perf: imx_ddr: Add support for NXP i.MX9 SoC DDRC PMU driver
        perf/arm_cspmu: Decouple APMT dependency
        perf/arm_cspmu: Clean up ACPI dependency
        ACPI/APMT: Don't register invalid resource
        perf/arm_cspmu: Fix event attribute type
        perf: arm_cspmu: Set irq affinitiy only if overflow interrupt is used
        drivers/perf: hisi: Don't migrate perf to the CPU going to teardown
        drivers/perf: apple_m1: Force 63bit counters for M2 CPUs
        perf/arm-cmn: Fix DTC reset
        perf: qcom_l2_pmu: Make l2_cache_pmu_probe_cluster() more robust
        perf/arm-cci: Slightly optimize cci_pmu_sync_counters()
      
      * for-next/kpti:
        : Simplify KPTI trampoline exit code
        arm64: entry: Simplify tramp_alias macro and tramp_exit routine
        arm64: entry: Preserve/restore X29 even for compat tasks
      
      * for-next/missing-proto-warn:
        : Address -Wmissing-prototype warnings
        arm64: add alt_cb_patch_nops prototype
        arm64: move early_brk64 prototype to header
        arm64: signal: include asm/exception.h
        arm64: kaslr: add kaslr_early_init() declaration
        arm64: flush: include linux/libnvdimm.h
        arm64: module-plts: inline linux/moduleloader.h
        arm64: hide unused is_valid_bugaddr()
        arm64: efi: add efi_handle_corrupted_x18 prototype
        arm64: cpuidle: fix #ifdef for acpi functions
        arm64: kvm: add prototypes for functions called in asm
        arm64: spectre: provide prototypes for internal functions
        arm64: move cpu_suspend_set_dbg_restorer() prototype to header
        arm64: avoid prototype warnings for syscalls
        arm64: add scs_patch_vmlinux prototype
        arm64: xor-neon: mark xor_arm64_neon_*() static
      
      * for-next/iss2-decode:
        : Add decode of ISS2 to data abort reports
        arm64/esr: Add decode of ISS2 to data abort reporting
        arm64/esr: Use GENMASK() for the ISS mask
      
      * for-next/kselftest:
        : Various arm64 kselftest improvements
        kselftest/arm64: Log signal code and address for unexpected signals
        kselftest/arm64: Add a smoke test for ptracing hardware break/watch points
      
      * for-next/misc:
        : Miscellaneous patches
        arm64: alternatives: make clean_dcache_range_nopatch() noinstr-safe
        arm64: hibernate: remove WARN_ON in save_processor_state
        arm64/fpsimd: Exit streaming mode when flushing tasks
        arm64: mm: fix VA-range sanity check
        arm64/mm: remove now-superfluous ISBs from TTBR writes
        arm64: consolidate rox page protection logic
        arm64: set __exception_irq_entry with __irq_entry as a default
        arm64: syscall: unmask DAIF for tracing status
        arm64: lockdep: enable checks for held locks when returning to userspace
        arm64/cpucaps: increase string width to properly format cpucaps.h
        arm64/cpufeature: Use helper for ECV CNTPOFF cpufeature
      
      * for-next/feat_mops:
        : Support for ARMv8.8 memcpy instructions in userspace
        kselftest/arm64: add MOPS to hwcap test
        arm64: mops: allow disabling MOPS from the kernel command line
        arm64: mops: detect and enable FEAT_MOPS
        arm64: mops: handle single stepping after MOPS exception
        arm64: mops: handle MOPS exceptions
        KVM: arm64: hide MOPS from guests
        arm64: mops: don't disable host MOPS instructions from EL2
        arm64: mops: document boot requirements for MOPS
        KVM: arm64: switch HCRX_EL2 between host and guest
        arm64: cpufeature: detect FEAT_HCX
        KVM: arm64: initialize HCRX_EL2
      
      * for-next/module-alloc:
        : Make the arm64 module allocation code more robust (clean-up, VA range expansion)
        arm64: module: rework module VA range selection
        arm64: module: mandate MODULE_PLTS
        arm64: module: move module randomization to module.c
        arm64: kaslr: split kaslr/module initialization
        arm64: kasan: remove !KASAN_VMALLOC remnants
        arm64: module: remove old !KASAN_VMALLOC logic
      
      * for-next/sysreg: (21 commits)
        : More sysreg conversions to automatic generation
        arm64/sysreg: Convert TRBIDR_EL1 register to automatic generation
        arm64/sysreg: Convert TRBTRG_EL1 register to automatic generation
        arm64/sysreg: Convert TRBMAR_EL1 register to automatic generation
        arm64/sysreg: Convert TRBSR_EL1 register to automatic generation
        arm64/sysreg: Convert TRBBASER_EL1 register to automatic generation
        arm64/sysreg: Convert TRBPTR_EL1 register to automatic generation
        arm64/sysreg: Convert TRBLIMITR_EL1 register to automatic generation
        arm64/sysreg: Rename TRBIDR_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBTRG_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBMAR_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBSR_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBBASER_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBPTR_EL1 fields per auto-gen tools format
        arm64/sysreg: Rename TRBLIMITR_EL1 fields per auto-gen tools format
        arm64/sysreg: Convert OSECCR_EL1 to automatic generation
        arm64/sysreg: Convert OSDTRTX_EL1 to automatic generation
        arm64/sysreg: Convert OSDTRRX_EL1 to automatic generation
        arm64/sysreg: Convert OSLAR_EL1 to automatic generation
        arm64/sysreg: Standardise naming of bitfield constants in OSL[AS]R_EL1
        arm64/sysreg: Convert MDSCR_EL1 to automatic register generation
        ...
      
      * for-next/cpucap:
        : arm64 cpucap clean-up
        arm64: cpufeature: fold cpus_set_cap() into update_cpu_capabilities()
        arm64: cpufeature: use cpucap naming
        arm64: alternatives: use cpucap naming
        arm64: standardise cpucap bitmap names
      
      * for-next/acpi:
        : Various arm64-related ACPI patches
        ACPI: bus: Consolidate all arm specific initialisation into acpi_arm_init()
      
      * for-next/kdump:
        : Simplify the crashkernel reservation behaviour of crashkernel=X,high on arm64
        arm64: add kdump.rst into index.rst
        Documentation: add kdump.rst to present crashkernel reservation on arm64
        arm64: kdump: simplify the reservation behaviour of crashkernel=,high
      
      * for-next/acpi-doc:
        : Update ACPI documentation for Arm systems
        Documentation/arm64: Update ACPI tables from BBR
        Documentation/arm64: Update references in arm-acpi
        Documentation/arm64: Update ARM and arch reference
      
      * for-next/doc:
        : arm64 documentation updates
        Documentation/arm64: Add ptdump documentation
      
      * for-next/tpidr2-fix:
        : Fix the TPIDR2_EL0 register restoring on sigreturn
        kselftest/arm64: Add a test case for TPIDR2 restore
        arm64/signal: Restore TPIDR2 register rather than memory state
      f42039d1
    • Mark Brown's avatar
      kselftest/arm64: Add a test case for TPIDR2 restore · f7a5d72e
      Mark Brown authored
      Due to the fact that TPIDR2 is intended to be managed by libc we don't
      currently test modifying it via the signal context since that might
      disrupt libc's usage of it and cause instability. We can however test the
      opposite case with less risk, modifying TPIDR2 in a signal handler and
      making sure that the original value is restored after returning from the
      signal handler. Add a test which does this.
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20230621-arm64-fix-tpidr2-signal-restore-v2-2-c8e8fcc10302@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f7a5d72e
    • Mark Brown's avatar
      arm64/signal: Restore TPIDR2 register rather than memory state · 616cb2f4
      Mark Brown authored
      Currently when restoring the TPIDR2 signal context we set the new value
      from the signal frame in the thread data structure but not the register,
      following the pattern for the rest of the data we are restoring. This does
      not work in the case of TPIDR2, the register always has the value for the
      current task. This means that either we return to userspace and ignore the
      new value or we context switch and save the register value on top of the
      newly restored value.
      
      Load the value from the signal context into the register instead.
      
      Fixes: 39e54499 ("arm64/signal: Include TPIDR2 in the signal context")
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: <stable@vger.kernel.org> # 6.3.x
      Link: https://lore.kernel.org/r/20230621-arm64-fix-tpidr2-signal-restore-v2-1-c8e8fcc10302@kernel.orgSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      616cb2f4
  2. 21 Jun, 2023 4 commits
  3. 19 Jun, 2023 1 commit
  4. 16 Jun, 2023 8 commits
  5. 15 Jun, 2023 2 commits
    • Mark Rutland's avatar
      arm64: mm: fix VA-range sanity check · ab9b4008
      Mark Rutland authored
      Both create_mapping_noalloc() and update_mapping_prot() sanity-check
      their 'virt' parameter, but the check itself doesn't make much sense.
      The condition used today appears to be a historical accident.
      
      The sanity-check condition:
      
      	if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
      		[ ... warning here ... ]
      		return;
      	}
      
      ... can only be true for the KASAN shadow region or the module region,
      and there's no reason to exclude these specifically for creating and
      updateing mappings.
      
      When arm64 support was first upstreamed in commit:
      
        c1cc1552 ("arm64: MMU initialisation")
      
      ... the condition was:
      
      	if (virt < VMALLOC_START) {
      		[ ... warning here ... ]
      		return;
      	}
      
      At the time, VMALLOC_START was the lowest kernel address, and this was
      checking whether 'virt' would be translated via TTBR1.
      
      Subsequently in commit:
      
        14c127c9 ("arm64: mm: Flip kernel VA space")
      
      ... the condition was changed to:
      
      	if ((virt >= VA_START) && (virt < VMALLOC_START)) {
      		[ ... warning here ... ]
      		return;
      	}
      
      This appear to have been a thinko. The commit moved the linear map to
      the bottom of the kernel address space, with VMALLOC_START being at the
      halfway point. The old condition would warn for changes to the linear
      map below this, and at the time VA_START was the end of the linear map.
      
      Subsequently we cleaned up the naming of VA_START in commit:
      
        77ad4ce6 ("arm64: memory: rename VA_START to PAGE_END")
      
      ... keeping the erroneous condition as:
      
      	if ((virt >= PAGE_END) && (virt < VMALLOC_START)) {
      		[ ... warning here ... ]
      		return;
      	}
      
      Correct the condition to check against the start of the TTBR1 address
      space, which is currently PAGE_OFFSET. This simplifies the logic, and
      more clearly matches the "outside kernel range" message in the warning.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Steve Capper <steve.capper@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Link: https://lore.kernel.org/r/20230615102628.1052103-1-mark.rutland@arm.comSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      ab9b4008
    • Jamie Iles's avatar
      arm64/mm: remove now-superfluous ISBs from TTBR writes · b9293d45
      Jamie Iles authored
      At the time of authoring 7655abb9 ("arm64: mm: Move ASID from TTBR0
      to TTBR1"), the Arm ARM did not specify any ordering guarantees for
      direct writes to TTBR0_ELx and TTBR1_ELx and so an ISB was required
      after each write to ensure TLBs would only be populated from the
      expected (or reserved tables).
      
      In a recent update to the Arm ARM, the requirements have been relaxed to
      reflect the implementation of current CPUs and required implementation
      of future CPUs to read (RDYDPX in D8.2.3 Translation table base address
      register):
      
        Direct writes to TTBR0_ELx and TTBR1_ELx occur in program order
        relative to one another, without the need for explicit
        synchronization. For any one translation, all indirect reads of
        TTBR0_ELx and TTBR1_ELx that are made as part of the translation
        observe only one point in that order of direct writes.
      
      Remove the superfluous ISBs to optimize uaccess helpers and context
      switch.
      
      Cc: Will Deacon <will@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarJamie Iles <quic_jiles@quicinc.com>
      Reviewed-by: default avatarMark Rutland <mark.rutland@arm.com>
      Link: https://lore.kernel.org/r/20230613141959.92697-1-quic_jiles@quicinc.com
      [catalin.marinas@arm.com: rename __cpu_set_reserved_ttbr0 to ..._nosync]
      [catalin.marinas@arm.com: move the cpu_set_reserved_ttbr0_nosync() call to cpu_do_switch_mm()]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b9293d45
  6. 14 Jun, 2023 18 commits
  7. 13 Jun, 2023 1 commit
  8. 09 Jun, 2023 2 commits
    • Baoquan He's avatar
      Documentation: add kdump.rst to present crashkernel reservation on arm64 · 03dc0e05
      Baoquan He authored
      People complained the crashkernel reservation code flow is hard to
      follow, so add this document to explain the background, concepts and
      implementation of crashkernel reservation on arm64. Hope this can help
      people to understand it more easily.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Reviewed-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
      Link: https://lore.kernel.org/r/20230515060259.830662-3-bhe@redhat.com
      [catalin.marinas@arm.com: rewrote some sentences, removed others]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      03dc0e05
    • Baoquan He's avatar
      arm64: kdump: simplify the reservation behaviour of crashkernel=,high · 6c4dcadd
      Baoquan He authored
      On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
      suitable memory region top down. If the 'xM' of crashkernel high memory
      is reserved from high memory successfully, it will try to reserve
      crashkernel low memory later accoringly. Otherwise, it will try to search
      low memory area for the 'xM' suitable region. Please see the details in
      Documentation/admin-guide/kernel-parameters.txt.
      
      While we observed an unexpected case where a reserved region crosses the
      high and low meomry boundary. E.g on a system with 4G as low memory end,
      user added the kernel parameters like: 'crashkernel=512M,high', it could
      finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
      The crashkernel high region crossing low and high memory boudary will bring
      issues:
      
      1) For crashkernel=x,high, if getting crashkernel high region across
      low and high memory boundary, then user will see two memory regions in
      low memory, and one memory region in high memory. The two crashkernel
      low memory regions are confusing as shown in above example.
      
      2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
      and y <= 128M, when crashkernel high region crosses low and high memory
      boundary and the part of crashkernel high reservation below boundary is
      bigger than y, the expected crahskernel low reservation will be skipped.
      But the expected crashkernel high reservation is shrank and could not
      satisfy user space requirement.
      
      3) The crossing boundary behaviour of crahskernel high reservation is
      different than x86 arch. On x86_64, the low memory end is 4G fixedly,
      and the memory near 4G is reserved by system, e.g for mapping firmware,
      pci mapping, so the crashkernel reservation crossing boundary never happens.
      From distros point of view, this brings inconsistency and confusion. Users
      need to dig into x86 and arm64 system details to find out why.
      
      For kernel itself, the impact of issue 3) could be slight. While issue
      1) and 2) cause actual impact because it brings obscure semantics and
      behaviour to crashkernel=,high reservation.
      
      Here, for crashkernel=xM,high, search the high memory for the suitable
      region only in high memory. If failed, try reserving the suitable
      region only in low memory. Like this, the crashkernel high region will
      only exist in high memory, and crashkernel low region only exists in low
      memory. The reservation behaviour for crashkernel=,high is clearer and
      simpler.
      
      Note: RPi4 has different zone ranges than normal memory. Its DMA zone is
      0~1G, and DMA32 zone is 1G~4G if CONFIG_ZONE_DMA|DMA32 are enabled by
      default. The low memory end is 1G in order to validate all devices, high
      memory starts at 1G memory. However, for being consistent with normal
      arm64 system, its low memory end is still 1G, while reserving crashkernel
      high memory from 4G if crashkernel=size,high specified. This will remove
      confusion.
      
      With above change applied, summary of arm64 crashkernel reservation range:
      1)
      RPi4(zone DMA:0~1G; DMA32:1G~4G):
       crashkernel=size
        0~1G: low memory | 1G~top: high memory
      
       crashkernel=size,high
        0~1G: low memory | 4G~top: high memory
      
      2)
      Other normal system:
       crashkernel=size
       crashkernel=size,high
        0~4G: low memory | 4G~top: high memory
      
      3)
      Systems w/o zone DMA|DMA32
       crashkernel=size
       crashkernel=size,high
        0~top: low memory
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
      Link: https://lore.kernel.org/r/ZGIBSEoZ7VRVvP8H@MiWiFi-R3L-srvSigned-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6c4dcadd