linux-stable.git/arch/arm64/include, branch linux-6.8.y

arm64: Remove unnecessary irqflags alternative.h include

2024-05-30T07:49:11+00:00

[ Upstream commit 98631c4904bf6380834c8585ce50451f00eb5389 ]

Since commit 20af807d806d ("arm64: Avoid cpus_have_const_cap() for
ARM64_HAS_GIC_PRIO_MASKING"), the alternative.h include is not used,
so remove it.

Fixes: 20af807d806d ("arm64: Avoid cpus_have_const_cap() for ARM64_HAS_GIC_PRIO_MASKING")
Signed-off-by: Jinjie Ruan 
Link: https://lore.kernel.org/r/20240314063819.2636445-1-ruanjinjie@huawei.com
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

Reapply "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"

2024-05-30T07:48:40+00:00

commit f481bb32d60e45fb3d19ea68ce79c5629f3fc3a0 upstream.

This reverts commit b8995a18417088bb53f87c49d200ec72a9dd4ec1.

Ard managed to reproduce the dm-crypt corruption problem and got to the
bottom of it, so re-apply the problematic patch in preparation for
fixing things properly.

Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"

2024-05-30T07:48:40+00:00

commit b8995a18417088bb53f87c49d200ec72a9dd4ec1 upstream.

This reverts commit 2632e25217696712681dd1f3ecc0d71624ea3b23.

Johannes (and others) report data corruption with dm-crypt on Apple M1
which has been bisected to this change. Revert the offending commit
while we figure out what's going on.

Cc: stable@vger.kernel.org
Reported-by: Johannes Nixdorf 
Link: https://lore.kernel.org/all/D1B7GPIR9K1E.5JFV37G0YTIF@shadowice.org/
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: tlb: Fix TLBI RANGE operand

2024-04-17T09:23:24+00:00

commit e3ba51ab24fddef79fc212f9840de54db8fd1685 upstream.

KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
pages are collected by VMM and the page table entries become write
protected during live migration. Unfortunately, the operand passed
to the TLBI RANGE instruction isn't correctly sorted out due to the
commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()").
It leads to crash on the destination VM after live migration because
TLBs aren't flushed completely and some of the dirty pages are missed.

For example, I have a VM where 8GB memory is assigned, starting from
0x40000000 (1GB). Note that the host has 4KB as the base page size.
In the middile of migration, kvm_tlb_flush_vmid_range() is executed
to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to
__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3
and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported
by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned
from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop
in the __flush_tlb_range_op() until the variable @scale underflows
and becomes -9, 0xffff708000040000 is set as the operand. The operand
is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to
invalid @scale and @num.

Fix it by extending __TLBI_RANGE_NUM() to support the combination of
SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can
be returned from the macro, meaning the TLBs for 0x200000 pages in the
above example can be flushed in one shoot with SCALE#3 and NUM#31. The
macro TLBI_RANGE_MASK is dropped since no one uses it any more. The
comments are also adjusted accordingly.

Fixes: 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()")
Cc: stable@kernel.org # v6.6+
Reported-by: Yihuang Yu 
Suggested-by: Marc Zyngier 
Signed-off-by: Gavin Shan 
Reviewed-by: Catalin Marinas 
Reviewed-by: Ryan Roberts 
Reviewed-by: Anshuman Khandual 
Reviewed-by: Shaoqin Huang 
Link: https://lore.kernel.org/r/20240405035852.1532010-2-gshan@redhat.com
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2024-02-23T18:26:43+00:00

Pull arm64 fixes from Will Deacon:
 "A simple fix to a definition in the CXL PMU driver, a couple of
  patches to restore SME control registers on the resume path (since
  Arm's fast model now clears them) and a revert for our jump label asm
  constraints after Geert noticed they broke the build with GCC 5.5.

  There was then the ensuing discussion about raising the minimum GCC
  (and corresponding binutils) versions at [1], but for now we'll keep
  things working as they were until that goes ahead.

   - Revert fix to jump label asm constraints, as it regresses the build
     with some GCC 5.5 toolchains.

   - Restore SME control registers when resuming from suspend

   - Fix incorrect filter definition in CXL PMU driver"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/sme: Restore SMCR_EL1.EZT0 on exit from suspend
  arm64/sme: Restore SME registers on exit from suspend
  Revert "arm64: jump_label: use constraints "Si" instead of "i""
  perf: CXL: fix CPMU filter value mask length

arm64/sme: Restore SME registers on exit from suspend

2024-02-20T12:19:15+00:00

The fields in SMCR_EL1 and SMPRI_EL1 reset to an architecturally UNKNOWN
value. Since we do not otherwise manage the traps configured in this
register at runtime we need to reconfigure them after a suspend in case
nothing else was kind enough to preserve them for us.

The vector length will be restored as part of restoring the SME state for
the next SME using task.

Fixes: a1f4ccd25cc2 ("arm64/sme: Provide Kconfig for SME")
Reported-by: Jackson Cooper-Driver 
Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20240213-arm64-sme-resume-v3-1-17e05e493471@kernel.org
Signed-off-by: Will Deacon

Revert "arm64: jump_label: use constraints "Si" instead of "i""

2024-02-20T12:12:44+00:00

This reverts commit f9daab0ad01cf9d165dbbbf106ca4e61d06e7fe8.

Geert reports that his particular GCC 5.5 vintage toolchain fails to
build an arm64 defconfig because of this change:

 |    arch/arm64/include/asm/jump_label.h:25:2: error: invalid 'asm':
 | invalid operand
 |     asm goto(
      ^
Aopparently, this is something we claim to support, so let's revert back
to the old jump label constraint for now while discussions about raising
the minimum GCC version are ongoing.

Reported-by: Geert Uytterhoeven 
Link: https://lore.kernel.org/r/CAMuHMdX+6fnAf8Hm6EqYJPAjrrLO9T7c=Gu3S8V_pqjSDowJ6g@mail.gmail.com
Signed-off-by: Will Deacon

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

2024-02-16T18:28:29+00:00

Pull arm64 fixes from Will Deacon:
 "It's a little busier than normal, but it's still not a lot of code and
  things seem fairly quiet in general:

   - Fix allocation failure during SVE coredumps

   - Fix handling of SVE context on signal delivery

   - Enable Neoverse N2 CPU errata workarounds for Microsoft's "Azure
     Cobalt 100" clone

   - Work around CMN PMU erratum in AmpereOneX implementation

   - Fix typo in CXL PMU event definition

   - Fix jump label asm constraints"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/sve: Lower the maximum allocation for the SVE ptrace regset
  arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata
  perf/arm-cmn: Workaround AmpereOneX errata AC04_MESH_1 (incorrect child count)
  arm64: jump_label: use constraints "Si" instead of "i"
  arm64: fix typo in comments
  perf: CXL: fix mismatched cpmu event opcode
  arm64/signal: Don't assume that TIF_SVE means we saved SVE state

arm64/sve: Lower the maximum allocation for the SVE ptrace regset

2024-02-15T11:48:00+00:00

Doug Anderson observed that ChromeOS crashes are being reported which
include failing allocations of order 7 during core dumps due to ptrace
allocating storage for regsets:

  chrome: page allocation failure: order:7,
          mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
          nodemask=(null),cpuset=urgent,mems_allowed=0
   ...
  regset_get_alloc+0x1c/0x28
  elf_core_dump+0x3d8/0xd8c
  do_coredump+0xeb8/0x1378

with further investigation showing that this is:

   [   66.957385] DOUG: Allocating 279584 bytes

which is the maximum size of the SVE regset. As Doug observes it is not
entirely surprising that such a large allocation of contiguous memory might
fail on a long running system.

The SVE regset is currently sized to hold SVE registers with a VQ of
SVE_VQ_MAX which is 512, substantially more than the architectural maximum
of 16 which we might see even in a system emulating the limits of the
architecture. Since we don't expose the size we tell the regset core
externally let's define ARCH_SVE_VQ_MAX with the actual architectural
maximum and use that for the regset, we'll still overallocate most of the
time but much less so which will be helpful even if the core is fixed to
not require contiguous allocations.

Specify ARCH_SVE_VQ_MAX in terms of the maximum value that can be written
into ZCR_ELx.LEN (where this is set in the hardware). For consistency
update the maximum SME vector length to be specified in the same style
while we are at it.

We could also teach the ptrace core about runtime discoverable regset sizes
but that would be a more invasive change and this is being observed in
practical systems.

Reported-by: Doug Anderson 
Signed-off-by: Mark Brown 
Tested-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org
Signed-off-by: Will Deacon

arm64: Subscribe Microsoft Azure Cobalt 100 to ARM Neoverse N2 errata

2024-02-15T11:47:22+00:00

Add the MIDR value of Microsoft Azure Cobalt 100, which is a Microsoft
implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and therefore
suffers from all the same errata.

CC: stable@vger.kernel.org # 5.15+
Signed-off-by: Easwar Hariharan 
Reviewed-by: Anshuman Khandual 
Acked-by: Mark Rutland 
Acked-by: Marc Zyngier 
Reviewed-by: Oliver Upton 
Link: https://lore.kernel.org/r/20240214175522.2457857-1-eahariha@linux.microsoft.com
Signed-off-by: Will Deacon