]> git.ipfire.org Git - thirdparty/linux.git/log
thirdparty/linux.git
2 weeks agoMerge branch kvm-arm64/gicv5-prologue into kvmarm-master/next
Marc Zyngier [Thu, 5 Feb 2026 09:17:30 +0000 (09:17 +0000)] 
Merge branch kvm-arm64/gicv5-prologue into kvmarm-master/next

* kvm-arm64/gicv5-prologue:
  : .
  : Prologue to GICv5 support, courtesy of Sascha Bischoff.
  :
  : This is preliminary work that sets the scene for the full-blow
  : support.
  : .
  irqchip/gic-v5: Check if impl is virt capable
  KVM: arm64: gic: Set vgic_model before initing private IRQs
  arm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1
  KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2

Signed-off-by: Marc Zyngier <maz@kernel.org>
2 weeks agoMerge branch kvm-arm64/gicv3-tdir-fixes into kvmarm-master/next
Marc Zyngier [Thu, 5 Feb 2026 09:17:04 +0000 (09:17 +0000)] 
Merge branch kvm-arm64/gicv3-tdir-fixes into kvmarm-master/next

* kvm-arm64/gicv3-tdir-fixes:
  : .
  : Address two trapping-related issues when running legacy (i.e. GICv3)
  : guests on GICv5 hosts, courtesy of Sascha Bischoff.
  : .
  KVM: arm64: Correct test for ICH_HCR_EL2_TDIR cap for GICv5 hosts
  KVM: arm64: gic: Enable GICv3 CPUIF trapping on GICv5 hosts if required

Signed-off-by: Marc Zyngier <maz@kernel.org>
2 weeks agoMerge branch kvm-arm64/fwb-for-all into kvmarm-master/next
Marc Zyngier [Thu, 5 Feb 2026 09:16:42 +0000 (09:16 +0000)] 
Merge branch kvm-arm64/fwb-for-all into kvmarm-master/next

* kvm-arm64/fwb-for-all:
  : .
  : Allow pKVM's host stage-2 mappings to use the Force Write Back version
  : of the memory attributes by using the "pass-through' encoding.
  :
  : This avoids having two separate encodings for S2 on a given platform.
  : .
  KVM: arm64: Simplify PAGE_S2_MEMATTR
  KVM: arm64: Kill KVM_PGTABLE_S2_NOFWB
  KVM: arm64: Switch pKVM host S2 over to KVM_PGTABLE_S2_AS_S1
  KVM: arm64: Add KVM_PGTABLE_S2_AS_S1 flag
  arm64: Add MT_S2{,_FWB}_AS_S1 encodings

Signed-off-by: Marc Zyngier <maz@kernel.org>
2 weeks agoMerge branch kvm-arm64/pkvm-no-mte into kvmarm-master/next
Marc Zyngier [Thu, 5 Feb 2026 09:16:31 +0000 (09:16 +0000)] 
Merge branch kvm-arm64/pkvm-no-mte into kvmarm-master/next

* kvm-arm64/pkvm-no-mte:
  : .
  : pKVM updates preventing the host from using MTE-related system
  : sysrem registers when the feature is disabled from the kernel
  : command-line (arm64.nomte), courtesy of Fuad Taba.
  :
  : From the cover letter:
  :
  : "If MTE is supported by the hardware (and is enabled at EL3), it remains
  : available to lower exception levels by default. Disabling it in the host
  : kernel (e.g., via 'arm64.nomte') only stops the kernel from advertising
  : the feature; it does not physically disable MTE in the hardware.
  :
  : The ability to disable MTE in the host kernel is used by some systems,
  : such as Android, so that the physical memory otherwise used as tag
  : storage can be used for other things (i.e. treated just like the rest of
  : memory). In this scenario, a malicious host could still access tags in
  : pages donated to a guest using MTE instructions (e.g., STG and LDG),
  : bypassing the kernel's configuration."
  : .
  KVM: arm64: Use kvm_has_mte() in pKVM trap initialization
  KVM: arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled
  KVM: arm64: Trap MTE access and discovery when MTE is disabled
  KVM: arm64: Remove dead code resetting HCR_EL2 for pKVM

Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoirqchip/gic-v5: Check if impl is virt capable
Sascha Bischoff [Wed, 28 Jan 2026 18:07:33 +0000 (18:07 +0000)] 
irqchip/gic-v5: Check if impl is virt capable

Now that there is support for creating a GICv5-based guest with KVM,
check that the hardware itself supports virtualisation, skipping the
setting of struct gic_kvm_info if not.

Note: If native GICv5 virt is not supported, then nor is
FEAT_GCIE_LEGACY, so we are able to skip altogether.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260128175919.3828384-33-sascha.bischoff@arm.com
[maz: cosmetic changes]
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: gic: Set vgic_model before initing private IRQs
Sascha Bischoff [Wed, 28 Jan 2026 18:00:52 +0000 (18:00 +0000)] 
KVM: arm64: gic: Set vgic_model before initing private IRQs

Different GIC types require the private IRQs to be initialised
differently. GICv5 is the culprit as it supports both a different
number of private IRQs, and all of these are PPIs (there are no
SGIs). Moreover, as GICv5 uses the top bits of the interrupt ID to
encode the type, the intid also needs to computed differently.

Up until now, the GIC model has been set after initialising the
private IRQs for a VCPU. Move this earlier to ensure that the GIC
model is available when configuring the private IRQs. While we're at
it, also move the setting of the in_kernel flag and implementation
revision to keep them grouped together as before.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260128175919.3828384-7-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoarm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1
Sascha Bischoff [Wed, 28 Jan 2026 18:00:06 +0000 (18:00 +0000)] 
arm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1

The GICv5 architecture is dropping the ICC_HAPR_EL1 and ICV_HAPR_EL1
system registers. These registers were never added to the sysregs, but
the traps for them were.

Drop the trap bit from the ICH_HFGRTR_EL2 and make it Res1 as per the
upcoming GICv5 spec change. Additionally, update the EL2 setup code to
not attempt to set that bit.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260128175919.3828384-4-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2
Sascha Bischoff [Wed, 28 Jan 2026 17:59:50 +0000 (17:59 +0000)] 
KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2

The VGIC-v3 code relied on hand-written definitions for the
ICH_VMCR_EL2 register. This register, and the associated fields, is
now generated as part of the sysreg framework. Move to using the
generated definitions instead of the hand-written ones.

There are no functional changes as part of this change.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260128175919.3828384-3-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: Correct test for ICH_HCR_EL2_TDIR cap for GICv5 hosts
Sascha Bischoff [Mon, 8 Dec 2025 15:28:23 +0000 (15:28 +0000)] 
KVM: arm64: Correct test for ICH_HCR_EL2_TDIR cap for GICv5 hosts

The original order of checks in the ICH_HCR_EL2_TDIR test returned
with false early in the case where the native GICv3 CPUIF was not
present. The result was that on GICv5 hosts with legacy support -
which do not have the GICv3 CPUIF - the test always returned false.

Reshuffle the checks such that support for GICv5 legacy is checked
prior to checking for the native GICv3 CPUIF.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Fixes: 2a28810cbb8b2 ("KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping")
Link: https://patch.msgid.link/20251208152724.3637157-4-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: gic: Enable GICv3 CPUIF trapping on GICv5 hosts if required
Sascha Bischoff [Mon, 8 Dec 2025 15:28:22 +0000 (15:28 +0000)] 
KVM: arm64: gic: Enable GICv3 CPUIF trapping on GICv5 hosts if required

Factor out the enable (and printing of) the GICv3 CPUIF traps from the
main GICv3 probe into a separate function. Call said function from the
GICv5 probe for legacy support, ensuring that any required GICv3 CPUIF
traps on GICv5 hosts will be correctly handled, rather than injecting
an undef into the guest.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20251208152724.3637157-3-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: Simplify PAGE_S2_MEMATTR
Marc Zyngier [Fri, 23 Jan 2026 19:16:37 +0000 (19:16 +0000)] 
KVM: arm64: Simplify PAGE_S2_MEMATTR

Restore PAGE_S2_MEMATTR() to its former glory, keeping the use of
FWB as an implementation detail.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260123191637.715429-6-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: Kill KVM_PGTABLE_S2_NOFWB
Marc Zyngier [Fri, 23 Jan 2026 19:16:36 +0000 (19:16 +0000)] 
KVM: arm64: Kill KVM_PGTABLE_S2_NOFWB

Nobody is using this flag anymore, so remove it. This allows
some cleanup by removing stage2_has_fwb(), which is can be replaced
by a direct check on the capability.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260123191637.715429-5-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: Switch pKVM host S2 over to KVM_PGTABLE_S2_AS_S1
Marc Zyngier [Fri, 23 Jan 2026 19:16:35 +0000 (19:16 +0000)] 
KVM: arm64: Switch pKVM host S2 over to KVM_PGTABLE_S2_AS_S1

Since we have the basics to use the S1 memory attributes as the
final ones with FWB, flip the host over to that when FWB is present.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260123191637.715429-4-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoKVM: arm64: Add KVM_PGTABLE_S2_AS_S1 flag
Marc Zyngier [Fri, 23 Jan 2026 19:16:34 +0000 (19:16 +0000)] 
KVM: arm64: Add KVM_PGTABLE_S2_AS_S1 flag

Plumb the MT_S2{,_FWB}_AS_S1 memory types into the KVM_S2_MEMATTR()
macro with a new KVM_PGTABLE_S2_AS_S1 flag.

Nobody selects it yet.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260123191637.715429-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
3 weeks agoarm64: Add MT_S2{,_FWB}_AS_S1 encodings
Marc Zyngier [Fri, 23 Jan 2026 19:16:33 +0000 (19:16 +0000)] 
arm64: Add MT_S2{,_FWB}_AS_S1 encodings

pKVM usage of S2 translation on the host is purely for isolation
purposes, not translation. To that effect, the memory attributes
being used must be that of S1.

With FWB=0, this is easily achieved by using the Normal Cacheable
type (which is the weakest possible memory type) at S2, and let S1
pick something stronger as required.

With FWB=1, the attributes are combined in a different way, and we
cannot arbitrarily use Normal Cacheable. We can, however, use a
memattr encoding that indicates that the final attributes are that
of Stage-1.

Add these encoding and a few pointers to the relevant parts of the
specification. It might come handy some day.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260123191637.715429-2-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoKVM: arm64: Use kvm_has_mte() in pKVM trap initialization
Fuad Tabba [Thu, 22 Jan 2026 11:22:18 +0000 (11:22 +0000)] 
KVM: arm64: Use kvm_has_mte() in pKVM trap initialization

When initializing HCR traps in protected mode, use kvm_has_mte() to
check for MTE support rather than kvm_has_feat(kvm, ID_AA64PFR1_EL1,
MTE, IMP).

kvm_has_mte() provides a more comprehensive check:
 - kvm_has_feat() only checks if MTE is in the guest's ID register view
   (i.e., what we advertise to the guest)
 - kvm_has_mte() checks both system_supports_mte() AND whether
   KVM_ARCH_FLAG_MTE_ENABLED is set for this VM instance

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260122112218.531948-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoKVM: arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled
Fuad Tabba [Thu, 22 Jan 2026 11:22:17 +0000 (11:22 +0000)] 
KVM: arm64: Inject UNDEF when accessing MTE sysregs with MTE disabled

When MTE hardware is present but disabled via software (`arm64.nomte` or
`CONFIG_ARM64_MTE=n`), the kernel clears `HCR_EL2.ATA` and sets
`HCR_EL2.TID5`, to prevent the use of MTE instructions.

Additionally, accesses to certain MTE system registers trap to EL2 with
exception class ESR_ELx_EC_SYS64. To emulate hardware without MTE (where
such accesses would cause an Undefined Instruction exception), inject
UNDEF into the host.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260122112218.531948-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoKVM: arm64: Trap MTE access and discovery when MTE is disabled
Fuad Tabba [Thu, 22 Jan 2026 11:22:16 +0000 (11:22 +0000)] 
KVM: arm64: Trap MTE access and discovery when MTE is disabled

If MTE is not supported by the hardware, or is disabled in the kernel
configuration (`CONFIG_ARM64_MTE=n`) or command line (`arm64.nomte`),
the kernel stops advertising MTE to userspace and avoids using MTE
instructions. However, this is a software-level disable only.

When MTE hardware is present and enabled by EL3 firmware, leaving
`HCR_EL2.ATA` set allows the host to execute MTE instructions (STG, LDG,
etc.) and access allocation tags in physical memory.

Prevent this by clearing `HCR_EL2.ATA` when MTE is disabled. Remove it
from the `HCR_HOST_NVHE_FLAGS` default, and conditionally set it in
`cpu_prepare_hyp_mode()` only when `system_supports_mte()` returns true.
This causes MTE instructions to trap to EL2 when `HCR_EL2.ATA` is
cleared.

Additionally, set `HCR_EL2.TID5` when MTE is disabled. This traps reads
of `GMID_EL1` (Multiple tag transfer ID register) to EL2, preventing the
discovery of MTE parameters (such as tag block size) when the feature is
suppressed.

Early boot code in `head.S` temporarily keeps `HCR_ATA` set to avoid
special-casing initialization paths. This is safe because this code
executes before untrusted code runs and will clear `HCR_ATA` if MTE is
disabled.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260122112218.531948-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoKVM: arm64: Remove dead code resetting HCR_EL2 for pKVM
Fuad Tabba [Thu, 22 Jan 2026 11:22:15 +0000 (11:22 +0000)] 
KVM: arm64: Remove dead code resetting HCR_EL2 for pKVM

The pKVM lifecycle does not support tearing down the hypervisor and
returning to the hyp stub once initialized. The transition to protected
mode is one-way.

Consequently, the code path in hyp-init.S responsible for resetting
EL2 registers (triggered by kexec or hibernation) is unreachable in
protected mode.

Remove the dead code handling HCR_EL2 reset for
ARM64_KVM_PROTECTED_MODE.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260122112218.531948-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoMerge branch kvm-arm64/pkvm-features-6.20 into kvmarm-master/next
Marc Zyngier [Fri, 23 Jan 2026 10:04:47 +0000 (10:04 +0000)] 
Merge branch kvm-arm64/pkvm-features-6.20 into kvmarm-master/next

* kvm-arm64/pkvm-features-6.20:
  : .
  : pKVM guest feature trapping fixes, courtesy of Fuad Tabba.
  : .
  KVM: arm64: Prevent host from managing timer offsets for protected VMs
  KVM: arm64: Check whether a VM IOCTL is allowed in pKVM
  KVM: arm64: Track KVM IOCTLs and their associated KVM caps
  KVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest in pKVM
  KVM: arm64: Include VM type when checking VM capabilities in pKVM
  KVM: arm64: Introduce helper to calculate fault IPA offset
  KVM: arm64: Fix MTE flag initialization for protected VMs
  KVM: arm64: Fix Trace Buffer trap polarity for protected VMs
  KVM: arm64: Fix Trace Buffer trapping for protected VMs

Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoMerge branch kvm-arm64/feat_idst into kvmarm-master/next
Marc Zyngier [Fri, 23 Jan 2026 10:04:35 +0000 (10:04 +0000)] 
Merge branch kvm-arm64/feat_idst into kvmarm-master/next

* kvm-arm64/feat_idst:
  : .
  : Add support for FEAT_IDST, allowing ID registers that are not implemented
  : to be reported as a normal trap rather than as an UNDEF exception.
  : .
  KVM: arm64: selftests: Add a test for FEAT_IDST
  KVM: arm64: pkvm: Report optional ID register traps with a 0x18 syndrome
  KVM: arm64: pkvm: Add a generic synchronous exception injection primitive
  KVM: arm64: Force trap of GMID_EL1 when the guest doesn't have MTE
  KVM: arm64: Handle CSSIDR2_EL1 and SMIDR_EL1 in a generic way
  KVM: arm64: Handle FEAT_IDST for sysregs without specific handlers
  KVM: arm64: Add a generic synchronous exception injection primitive
  KVM: arm64: Add trap routing for GMID_EL1
  arm64: Repaint ID_AA64MMFR2_EL1.IDS description

Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoMerge branch kvm-arm64/selftests-6.20 into kvmarm-master/next
Marc Zyngier [Fri, 23 Jan 2026 10:04:20 +0000 (10:04 +0000)] 
Merge branch kvm-arm64/selftests-6.20 into kvmarm-master/next

* kvm-arm64/selftests-6.20:
  : .
  : Some selftest fixes addressing page alignment issues as well as
  : a bad MMU setup bug, courtesy of Fuad Tabba.
  : .
  KVM: selftests: Fix typos and stale comments in kvm_util
  KVM: selftests: Move page_align() to shared header
  KVM: riscv: selftests: Fix incorrect rounding in page_align()
  KVM: arm64: selftests: Fix incorrect rounding in page_align()
  KVM: arm64: selftests: Disable unused TTBR1_EL1 translations

Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoMerge branch kvm-arm64/vtcr into kvmarm-master/next
Marc Zyngier [Fri, 23 Jan 2026 10:03:03 +0000 (10:03 +0000)] 
Merge branch kvm-arm64/vtcr into kvmarm-master/next

* kvm-arm64/vtcr:
  : .
  : VTCR_EL2 conversion to the configuration-driven RESx framework,
  : fixing a couple of UXN/PXN/XN bugs in the process.
  : .
  KVM: arm64: nv: Return correct RES0 bits for FGT registers
  KVM: arm64: Always populate FGT masks at boot time
  KVM: arm64: Honor UX/PX attributes for EL2 S1 mappings
  KVM: arm64: Convert VTCR_EL2 to config-driven sanitisation
  KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co
  arm64: Convert VTCR_EL2 to sysreg infratructure
  arm64: Convert ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 to UnsignedEnum
  KVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers
  KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit
  KVM: arm64: nv: Respect stage-2 write permssion when setting stage-1 AF
  KVM: arm64: Remove unused vcpu_{clear,set}_wfx_traps()
  KVM: arm64: Remove unused parameter in synchronize_vcpu_pstate()
  KVM: arm64: Remove extra argument for __pvkm_host_{share,unshare}_hyp()
  KVM: arm64: Inject UNDEF for a register trap without accessor
  KVM: arm64: Copy FGT traps to unprotected pKVM VCPU on VCPU load
  KVM: arm64: Fix EL2 S1 XN handling for hVHE setups
  KVM: arm64: gic: Check for vGICv3 when clearing TWI

Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoMerge branch arm64/for-next/cpufeature into kvmarm-master/next
Marc Zyngier [Fri, 23 Jan 2026 09:51:57 +0000 (09:51 +0000)] 
Merge branch arm64/for-next/cpufeature into kvmarm-master/next

Merge arm64/for-next/cpufeature in to resolve conflicts resulting from
the removal of CONFIG_PAN.

* arm64/for-next/cpufeature:
  arm64: Add support for FEAT_{LS64, LS64_V}
  KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest
  arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1
  KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory
  KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B
  KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots
  arm64: Unconditionally enable PAN support
  arm64: Unconditionally enable LSE support
  arm64: Add support for TSV110 Spectre-BHB mitigation

Signed-off-by: Marc Zyngier <maz@kernel.org>
4 weeks agoarm64: Add support for FEAT_{LS64, LS64_V}
Yicong Yang [Mon, 19 Jan 2026 02:29:27 +0000 (10:29 +0800)] 
arm64: Add support for FEAT_{LS64, LS64_V}

Armv8.7 introduces single-copy atomic 64-byte loads and stores
instructions and its variants named under FEAT_{LS64, LS64_V}.
These features are identified by ID_AA64ISAR1_EL1.LS64 and the
use of such instructions in userspace (EL0) can be trapped.

As st64bv (FEAT_LS64_V) and st64bv0 (FEAT_LS64_ACCDATA) can not be tell
apart, FEAT_LS64 and FEAT_LS64_ACCDATA which will be supported in later
patch will be exported to userspace, FEAT_LS64_V will be enabled only
in kernel.

In order to support the use of corresponding instructions in userspace:
- Make ID_AA64ISAR1_EL1.LS64 visbile to userspace
- Add identifying and enabling in the cpufeature list
- Expose these support of these features to userspace through HWCAP3
  and cpuinfo

ld64b/st64b (FEAT_LS64) and st64bv (FEAT_LS64_V) is intended for
special memory (device memory) so requires support by the CPU, system
and target memory location (device that support these instructions).
The HWCAP3_LS64, implies the support of CPU and system (since no
identification method from system, so SoC vendors should advertise
support in the CPU if system also support them).

Otherwise for ld64b/st64b the atomicity may not be guaranteed or a
DABT will be generated, so users (probably userspace driver developer)
should make sure the target memory (device) also have the support.
For st64bv 0xffffffffffffffff will be returned as status result for
unsupported memory so user should check it.

Document the restrictions along with HWCAP3_LS64.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoKVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest
Yicong Yang [Mon, 19 Jan 2026 02:29:26 +0000 (10:29 +0800)] 
KVM: arm64: Enable FEAT_{LS64, LS64_V} in the supported guest

Using FEAT_{LS64, LS64_V} instructions in a guest is also controlled
by HCRX_EL2.{EnALS, EnASR}. Enable it if guest has related feature.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoarm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1
Yicong Yang [Mon, 19 Jan 2026 02:29:25 +0000 (10:29 +0800)] 
arm64: Provide basic EL2 setup for FEAT_{LS64, LS64_V} usage at EL0/1

Instructions introduced by FEAT_{LS64, LS64_V} is controlled by
HCRX_EL2.{EnALS, EnASR}. Configure all of these to allow usage
at EL0/1.

This doesn't mean these instructions are always available in
EL0/1 if provided. The hypervisor still have the control at
runtime.

Acked-by: Will Deacon <will@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoKVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory
Yicong Yang [Mon, 19 Jan 2026 02:29:24 +0000 (10:29 +0800)] 
KVM: arm64: Handle DABT caused by LS64* instructions on unsupported memory

If FEAT_LS64WB not supported, FEAT_LS64* instructions only support
to access Device/Uncacheable memory, otherwise a data abort for
unsupported Exclusive or atomic access (0x35, UAoEF) is generated
per spec. It's implementation defined whether the target exception
level is routed and is possible to implemented as route to EL2 on a
VHE VM according to DDI0487L.b Section C3.2.6 Single-copy atomic
64-byte load/store.

If it's implemented as generate the DABT to the final enabled stage
(stage-2), inject the UAoEF back to the guest after checking the
memslot is valid.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoKVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B
Marc Zyngier [Mon, 19 Jan 2026 02:29:23 +0000 (10:29 +0800)] 
KVM: arm64: Add documentation for KVM_EXIT_ARM_LDST64B

Add a bit of documentation for KVM_EXIT_ARM_LDST64B so that userspace
knows what to expect.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoKVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots
Marc Zyngier [Mon, 19 Jan 2026 02:29:22 +0000 (10:29 +0800)] 
KVM: arm64: Add exit to userspace on {LD,ST}64B* outside of memslots

The main use of {LD,ST}64B* is to talk to a device, which is hopefully
directly assigned to the guest and requires no additional handling.

However, this does not preclude a VMM from exposing a virtual device
to the guest, and to allow 64 byte accesses as part of the programming
interface. A direct consequence of this is that we need to be able
to forward such access to userspace.

Given that such a contraption is very unlikely to ever exist, we choose
to offer a limited service: userspace gets (as part of a new exit reason)
the ESR, the IPA, and that's it. It is fully expected to handle the full
semantics of the instructions, deal with ACCDATA, the return values and
increment PC. Much fun.

A canonical implementation can also simply inject an abort and be done
with it. Frankly, don't try to do anything else unless you have time
to waste.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoarm64: Unconditionally enable PAN support
Marc Zyngier [Wed, 7 Jan 2026 18:07:00 +0000 (18:07 +0000)] 
arm64: Unconditionally enable PAN support

FEAT_PAN has been around since ARMv8.1 (over 11 years ago), has no compiler
dependency (we have our own accessors), and is a great security benefit.

Drop CONFIG_ARM64_PAN, and make the support unconditionnal.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoarm64: Unconditionally enable LSE support
Marc Zyngier [Wed, 7 Jan 2026 18:06:59 +0000 (18:06 +0000)] 
arm64: Unconditionally enable LSE support

LSE atomics have been in the architecture since ARMv8.1 (released in
2014), and are hopefully supported by all modern toolchains.

Drop the optional nature of LSE support in the kernel, and always
compile the support in, as this really is very little code. LL/SC
still is the default, and the switch to LSE is done dynamically.

Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
4 weeks agoKVM: arm64: nv: Return correct RES0 bits for FGT registers
Zenghui Yu (Huawei) [Wed, 21 Jan 2026 10:16:31 +0000 (18:16 +0800)] 
KVM: arm64: nv: Return correct RES0 bits for FGT registers

We had extended the sysreg masking infrastructure to more general
registers, instead of restricting it to VNCR-backed registers, since
commit a0162020095e ("KVM: arm64: Extend masking facility to arbitrary
registers"). Fix kvm_get_sysreg_res0() to reflect this fact.

Note that we're sure that we only deal with FGT registers in
kvm_get_sysreg_res0(), the

if (sr < __VNCR_START__)

is actually a never false, which should probably be removed later.

Fixes: 69c19e047dfe ("KVM: arm64: Add TCR2_EL2 to the sysreg arrays")
Signed-off-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
Link: https://patch.msgid.link/20260121101631.41037-1-zenghui.yu@linux.dev
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
4 weeks agoKVM: arm64: Always populate FGT masks at boot time
Marc Zyngier [Thu, 22 Jan 2026 08:51:53 +0000 (08:51 +0000)] 
KVM: arm64: Always populate FGT masks at boot time

We currently only populate the FGT masks if the underlying HW does
support FEAT_FGT. However, with the addition of the RES1 support for
system registers, this results in a lot of noise at boot time, as
reported by Nathan.

That's because even if FGT isn't supported, we still check for the
attribution of the bits to particular features, and not keeping the
masks up-to-date leads to (fairly harmess) warnings.

Given that we want these checks to be enforced even if the HW doesn't
support FGT, enable the generation of FGT masks unconditionally (this
is rather cheap anyway). Only the storage of the FGT configuration is
avoided, which will save a tiny bit of memory on these machines.

Reported-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Fixes: c259d763e6b09 ("KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co")
Link: https://lore.kernel.org/r/20260120211558.GA834868@ax162
Link: https://patch.msgid.link/20260122085153.535538-1-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Prevent host from managing timer offsets for protected VMs
Fuad Tabba [Thu, 11 Dec 2025 10:47:09 +0000 (10:47 +0000)] 
KVM: arm64: Prevent host from managing timer offsets for protected VMs

For protected VMs, the guest's timer offset state should not be
controlled by the host and must always run with a virtual counter offset
of 0. The existing timer logic allowed the host to set and manage the
timer counter offsets for protected VMs in certain cases.

Disable all host-side management of timer offsets for protected VMs by
adding checks in the relevant code paths.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-10-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Check whether a VM IOCTL is allowed in pKVM
Fuad Tabba [Thu, 11 Dec 2025 10:47:08 +0000 (10:47 +0000)] 
KVM: arm64: Check whether a VM IOCTL is allowed in pKVM

Certain VM IOCTLs are tied to specific VM features. Since pKVM does not
support all features, restrict which IOCTLs are allowed depending on
whether the associated feature is supported.

Use the existing VM capability check as the source of truth to whether
an IOCTL is allowed for a particular VM by mapping the IOCTLs with their
associated capabilities.

Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-9-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Track KVM IOCTLs and their associated KVM caps
Fuad Tabba [Thu, 11 Dec 2025 10:47:07 +0000 (10:47 +0000)] 
KVM: arm64: Track KVM IOCTLs and their associated KVM caps

Track KVM IOCTLs (VM IOCTLs for now), and the associated KVM capability
that enables that IOCTL. Add a function that performs the lookup.

This will be used by CoCo VM Hypervisors (e.g., pKVM) to determine
whether a particular KVM IOCTL is allowed for its VMs.

Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Fuad Tabba <tabba@google.com>
[maz: don't expose KVM_CAP_BASIC to userspace, and rely on NR_VCPUS
      as a proxy for this]
Link: https://patch.msgid.link/20251211104710.151771-8-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest in pKVM
Fuad Tabba [Thu, 11 Dec 2025 10:47:06 +0000 (10:47 +0000)] 
KVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest in pKVM

Supporting MTE in pKVM introduces significant complexity to the
hypervisor at EL2, even for non-protected VMs, since it would require
EL2 to handle tag management.

For now, do not allow KVM_CAP_ARM_MTE for any VM type in protected mode.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-7-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Include VM type when checking VM capabilities in pKVM
Fuad Tabba [Thu, 11 Dec 2025 10:47:05 +0000 (10:47 +0000)] 
KVM: arm64: Include VM type when checking VM capabilities in pKVM

Certain features and capabilities are restricted in protected mode. Most
of these features are restricted only for protected VMs, but some
are restricted for ALL VMs in protected mode.

Extend the pKVM capability check to pass the VM (kvm), and use that when
determining supported features.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-6-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Introduce helper to calculate fault IPA offset
Fuad Tabba [Thu, 11 Dec 2025 10:47:04 +0000 (10:47 +0000)] 
KVM: arm64: Introduce helper to calculate fault IPA offset

This 12-bit FAR fault IPA offset mask is hard-coded as 'GENMASK(11, 0)'
in several places to reconstruct the full fault IPA.

Introduce FAR_TO_FIPA_OFFSET() to calculate this value in a shared
header and replace all open-coded instances to improve readability.

No functional change intended.

Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Fix MTE flag initialization for protected VMs
Fuad Tabba [Thu, 11 Dec 2025 10:47:03 +0000 (10:47 +0000)] 
KVM: arm64: Fix MTE flag initialization for protected VMs

The function pkvm_init_features_from_host() initializes guest
features, propagating them from the host. The logic to propagate
KVM_ARCH_FLAG_MTE_ENABLED (Memory Tagging Extension)
has a couple of issues.

First, the check was in the common path, before the divergence for
protected and non-protected VMs. For non-protected VMs, this was
unnecessary, as 'kvm->arch.flags' is completely overwritten by
host_arch_flags immediately after, which already contains the MTE flag.
For protected VMs, this was setting the flag even if the feature is not
allowed.

Second, the check was reading 'host_kvm->arch.flags' instead of using
the local 'host_arch_flags', which is read once from the host flags.

Fix these by moving the MTE flag check inside the protected-VM-only
path, checking if the feature is allowed, and changing it to use the
correct host_arch_flags local variable. This ensures non-protected VMs
get the flag via the bulk copy, and protected VMs get it via an explicit
check.

Fixes: b7f345fbc32a ("KVM: arm64: Fix FEAT_MTE in pKVM")
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Fix Trace Buffer trap polarity for protected VMs
Fuad Tabba [Thu, 11 Dec 2025 10:47:02 +0000 (10:47 +0000)] 
KVM: arm64: Fix Trace Buffer trap polarity for protected VMs

The E2TB bits in MDCR_EL2 control trapping of Trace Buffer system
register accesses. These accesses are trapped to EL2 when the bits are
clear.

The trap initialization logic for protected VMs in pvm_init_traps_mdcr()
had the polarity inverted. When a guest did not support the Trace Buffer
feature, the code was setting E2TB. This incorrectly disabled the trap,
potentially allowing a protected guest to access registers for a feature
it was not given.

Fix this by inverting the operation.

Fixes: f50758260bff ("KVM: arm64: Group setting traps for protected VMs by control register")
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Fix Trace Buffer trapping for protected VMs
Fuad Tabba [Thu, 11 Dec 2025 10:47:01 +0000 (10:47 +0000)] 
KVM: arm64: Fix Trace Buffer trapping for protected VMs

For protected VMs in pKVM, the hypervisor should trap accesses to trace
buffer system registers if Trace Buffer isn't supported by the VM.
However, the current code only traps if Trace Buffer External Mode isn't
supported.

Fix this by checking for FEAT_TRBE (Trace Buffer) rather than
FEAT_TRBE_EXT.

Fixes: 9d5261269098 ("KVM: arm64: Trap external trace for protected VMs")
Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251211104710.151771-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: selftests: Fix typos and stale comments in kvm_util
Fuad Tabba [Fri, 9 Jan 2026 08:22:18 +0000 (08:22 +0000)] 
KVM: selftests: Fix typos and stale comments in kvm_util

Fix minor documentation errors in `kvm_util.h` and `kvm_util.c`.

- Correct the argument description for `vcpu_args_set` in `kvm_util.h`,
  which incorrectly listed `vm` instead of `vcpu`.
- Fix a typo in the comment for `kvm_selftest_arch_init` ("exeucting" ->
  "executing").
- Correct the return value description for `vm_vaddr_unused_gap` in
  `kvm_util.c` to match the implementation, which returns an address "at
  or above" `vaddr_min`, not "at or below".

No functional change intended.

Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-6-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: selftests: Move page_align() to shared header
Fuad Tabba [Fri, 9 Jan 2026 08:22:17 +0000 (08:22 +0000)] 
KVM: selftests: Move page_align() to shared header

To avoid code duplication, move page_align() to the shared `kvm_util.h`
header file. Rename it to vm_page_align(), to make it clear that the
alignment is done with respect to the guest's base page size.

No functional change intended.

Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-5-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: riscv: selftests: Fix incorrect rounding in page_align()
Fuad Tabba [Fri, 9 Jan 2026 08:22:16 +0000 (08:22 +0000)] 
KVM: riscv: selftests: Fix incorrect rounding in page_align()

The implementation of `page_align()` in `processor.c` calculates
alignment incorrectly for values that are already aligned. Specifically,
`(v + vm->page_size) & ~(vm->page_size - 1)` aligns to the *next* page
boundary even if `v` is already page-aligned, potentially wasting a page
of memory.

Fix the calculation to use standard alignment logic: `(v + vm->page_size
- 1) & ~(vm->page_size - 1)`.

Fixes: 3e06cdf10520 ("KVM: selftests: Add initial support for RISC-V 64-bit")
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-4-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: selftests: Fix incorrect rounding in page_align()
Fuad Tabba [Fri, 9 Jan 2026 08:22:15 +0000 (08:22 +0000)] 
KVM: arm64: selftests: Fix incorrect rounding in page_align()

The implementation of `page_align()` in `processor.c` calculates
alignment incorrectly for values that are already aligned. Specifically,
`(v + vm->page_size) & ~(vm->page_size - 1)` aligns to the *next* page
boundary even if `v` is already page-aligned, potentially wasting a page
of memory.

Fix the calculation to use standard alignment logic: `(v + vm->page_size
- 1) & ~(vm->page_size - 1)`.

Fixes: 7a6629ef746d ("kvm: selftests: add virt mem support for aarch64")
Reviewed-by: Andrew Jones <andrew.jones@linux.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-3-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: selftests: Disable unused TTBR1_EL1 translations
Fuad Tabba [Fri, 9 Jan 2026 08:22:14 +0000 (08:22 +0000)] 
KVM: arm64: selftests: Disable unused TTBR1_EL1 translations

KVM selftests map all guest code and data into the lower virtual address
range (0x0000...) managed by TTBR0_EL1. The upper range (0xFFFF...)
managed by TTBR1_EL1 is unused and uninitialized.

If a guest accesses the upper range, the MMU attempts a translation
table walk using uninitialized registers, leading to unpredictable
behavior.

Set `TCR_EL1.EPD1` to disable translation table walks for TTBR1_EL1,
ensuring that any access to the upper range generates an immediate
Translation Fault. Additionally, set `TCR_EL1.TBI1` (Top Byte Ignore) to
ensure that tagged pointers in the upper range also deterministically
trigger a Translation Fault via EPD1.

Define `TCR_EPD1_MASK`, `TCR_EPD1_SHIFT`, and `TCR_TBI1` in
`processor.h` to support this configuration. These are based on their
definitions in `arch/arm64/include/asm/pgtable-hwdef.h`.

Suggested-by: Will Deacon <will@kernel.org>
Reviewed-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260109082218.3236580-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: selftests: Add a test for FEAT_IDST
Marc Zyngier [Thu, 8 Jan 2026 17:32:33 +0000 (17:32 +0000)] 
KVM: arm64: selftests: Add a test for FEAT_IDST

Add a very basic test checking that FEAT_IDST actually works for
the {GMID,SMIDR,CSSIDR2}_EL1 registers.

Link: https://patch.msgid.link/20260108173233.2911955-10-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: pkvm: Report optional ID register traps with a 0x18 syndrome
Marc Zyngier [Thu, 8 Jan 2026 17:32:32 +0000 (17:32 +0000)] 
KVM: arm64: pkvm: Report optional ID register traps with a 0x18 syndrome

With FEAT_IDST, unimplemented system registers in the feature ID space
must be reported using EC=0x18 at the closest handling EL, rather than
with an UNDEF.

Most of these system registers are always implemented thanks to their
dependency on FEAT_AA64, except for a set of (currently) three registers:
GMID_EL1 (depending on MTE2), CCSIDR2_EL1 (depending on FEAT_CCIDX),
and SMIDR_EL1 (depending on SME).

For these three registers, report their trap as EC=0x18 if they
end-up trapping into KVM and that FEAT_IDST is implemented in the guest.
Otherwise, just make them UNDEF.

Link: https://patch.msgid.link/20260108173233.2911955-9-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: pkvm: Add a generic synchronous exception injection primitive
Marc Zyngier [Thu, 8 Jan 2026 17:32:31 +0000 (17:32 +0000)] 
KVM: arm64: pkvm: Add a generic synchronous exception injection primitive

Similarly to the "classic" KVM code, pKVM doesn't have an "anything
goes" synchronous exception injection primitive.

Carve one out of the UNDEF injection code.

Link: https://patch.msgid.link/20260108173233.2911955-8-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Force trap of GMID_EL1 when the guest doesn't have MTE
Marc Zyngier [Thu, 8 Jan 2026 17:32:30 +0000 (17:32 +0000)] 
KVM: arm64: Force trap of GMID_EL1 when the guest doesn't have MTE

If our host has MTE, but the guest doesn't, make sure we set HCR_EL2.TID5
to force GMID_EL1 being trapped. Such trap will be handled by the
FEAT_IDST handling.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260108173233.2911955-7-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Handle CSSIDR2_EL1 and SMIDR_EL1 in a generic way
Marc Zyngier [Thu, 8 Jan 2026 17:32:29 +0000 (17:32 +0000)] 
KVM: arm64: Handle CSSIDR2_EL1 and SMIDR_EL1 in a generic way

Now that we can handle ID registers using the FEAT_IDST infrastrcuture,
get rid of the handling of CSSIDR2_EL1 and SMIDR_EL1.

Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260108173233.2911955-6-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Handle FEAT_IDST for sysregs without specific handlers
Marc Zyngier [Thu, 8 Jan 2026 17:32:28 +0000 (17:32 +0000)] 
KVM: arm64: Handle FEAT_IDST for sysregs without specific handlers

Add a bit of infrastrtcture to triage_sysreg_trap() to handle the
case of registers falling into the Feature ID space that do not
have a local handler.

For these, we can directly apply the FEAT_IDST semantics and inject
an EC=0x18 exception. Otherwise, an UNDEF will do.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260108173233.2911955-5-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Add a generic synchronous exception injection primitive
Marc Zyngier [Thu, 8 Jan 2026 17:32:27 +0000 (17:32 +0000)] 
KVM: arm64: Add a generic synchronous exception injection primitive

Maybe in a surprising way, we don't currently have a generic way
to inject a synchronous exception at the EL the vcpu is currently
running at.

Extract such primitive from the UNDEF injection code.

Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260108173233.2911955-4-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Add trap routing for GMID_EL1
Marc Zyngier [Thu, 8 Jan 2026 17:32:26 +0000 (17:32 +0000)] 
KVM: arm64: Add trap routing for GMID_EL1

HCR_EL2.TID5 is currently ignored by the trap routing infrastructure.
Wire it in the routing table so that GMID_EL1, the sole register
trapped by this bit, is correctly handled in the NV case.

Link: https://patch.msgid.link/20260108173233.2911955-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoarm64: Repaint ID_AA64MMFR2_EL1.IDS description
Marc Zyngier [Thu, 8 Jan 2026 17:32:25 +0000 (17:32 +0000)] 
arm64: Repaint ID_AA64MMFR2_EL1.IDS description

ID_AA64MMFR2_EL1.IDS, as described in the sysreg file, is pretty horrible
as it diesctly give the ESR value. Repaint it using the usual NI/IMP
identifiers to describe the absence/presence of FEAT_IDST.

Also add the new EL3 routing feature, even if we really don't care about it.

Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Link: https://patch.msgid.link/20260108173233.2911955-2-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Honor UX/PX attributes for EL2 S1 mappings
Marc Zyngier [Wed, 10 Dec 2025 17:30:24 +0000 (17:30 +0000)] 
KVM: arm64: Honor UX/PX attributes for EL2 S1 mappings

Now that we potentially have two bits to deal with when setting
execution permissions, make sure we correctly handle them when both
when building the page tables and when reading back from them.

Reported-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251210173024.561160-7-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Convert VTCR_EL2 to config-driven sanitisation
Marc Zyngier [Wed, 10 Dec 2025 17:30:23 +0000 (17:30 +0000)] 
KVM: arm64: Convert VTCR_EL2 to config-driven sanitisation

Describe all the VTCR_EL2 fields and their respective configurations,
making sure that we correctly ignore the bits that are not defined
for a given guest configuration.

Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251210173024.561160-6-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoKVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co
Marc Zyngier [Wed, 10 Dec 2025 17:30:22 +0000 (17:30 +0000)] 
KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co

None of the registers we manage in the feature dependency infrastructure
so far has any RES1 bit. This is about to change, as VTCR_EL2 has
its bit 31 being RES1.

In order to not fail the consistency checks by not describing a bit,
add RES1 bits to the set of immutable bits. This requires some extra
surgery for the FGT handling, as we now need to track RES1 bits there
as well.

There are no RES1 FGT bits *yet*. Watch this space.

Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251210173024.561160-5-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoarm64: Convert VTCR_EL2 to sysreg infratructure
Marc Zyngier [Wed, 10 Dec 2025 17:30:21 +0000 (17:30 +0000)] 
arm64: Convert VTCR_EL2 to sysreg infratructure

Our definition of VTCR_EL2 is both partial (tons of fields are
missing) and totally inconsistent (some constants are shifted,
some are not). They are also expressed in terms of TCR, which is
rather inconvenient.

Replace the ad-hoc definitions with the the generated version.
This results in a bunch of additional changes to make the code
with the unshifted nature of generated enumerations.

The register data was extracted from the BSD licenced AARCHMRS
(AARCHMRS_OPENSOURCE_A_profile_FAT-2025-09_ASL0).

Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251210173024.561160-4-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoarm64: Convert ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 to UnsignedEnum
Marc Zyngier [Wed, 10 Dec 2025 17:30:20 +0000 (17:30 +0000)] 
arm64: Convert ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 to UnsignedEnum

ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 are currently represented as unordered
enumerations. However, the architecture treats them as Unsigned,
as hinted to by the MRS data:

(FEAT_S2TGran4K <=> (((UInt(ID_AA64MMFR0_EL1.TGran4_2) == 0) &&
       FEAT_TGran4K) ||
     (UInt(ID_AA64MMFR0_EL1.TGran4_2) >= 2))))

and similar descriptions exist for 16 and 64k.

This is also confirmed by D24.1.3.3 ("Alternative ID scheme used for
ID_AA64MMFR0_EL1 stage 2 granule sizes") in the L.b revision of
the ARM ARM.

Turn these fields into UnsignedEnum so that we can use the above
description more or less literally.

Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20251210173024.561160-3-maz@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 weeks agoMerge branch kvmarm-fixes-6.19-1 into kvm-arm64/vtcr
Marc Zyngier [Thu, 15 Jan 2026 10:53:31 +0000 (10:53 +0000)] 
Merge branch kvmarm-fixes-6.19-1 into kvm-arm64/vtcr

KVM/arm64 fixes for 6.19

 - Ensure early return semantics are preserved for pKVM fault handlers

 - Fix case where the kernel runs with the guest's PAN value when
   CONFIG_ARM64_PAN is not set

 - Make stage-1 walks to set the access flag respect the access
   permission of the underlying stage-2, when enabled

 - Propagate computed FGT values to the pKVM view of the vCPU at
   vcpu_load()

 - Correctly program PXN and UXN privilege bits for hVHE's stage-1 page
   tables

 - Check that the VM is actually using VGICv3 before accessing the GICv3
   CPU interface

 - Delete some unused code

# -----BEGIN PGP SIGNATURE-----
#
# iI0EABYKADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCaWiyJBccb2xpdmVyLnVw
# dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFqVhAQDM4Lbrq0F80X+YzvO7oxWioOy4
# JiTATSii9Lit8KY6fgEAvLD4qaggLdF3+WY+V37YmTj3UDgI31ClBr+xSvSengA=
# =XaL0
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 15 Jan 2026 09:23:48 GMT
# gpg:                using EDDSA key 8D5C78D65EECCC66EB6B28D2A2BE7588247CDD16
# gpg:                issuer "oliver.upton@linux.dev"
# gpg: Can't check signature: No public key

* tag 'kvmarm-fixes-6.19-1':
  KVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers
  KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit
  KVM: arm64: nv: Respect stage-2 write permssion when setting stage-1 AF
  KVM: arm64: Remove unused vcpu_{clear,set}_wfx_traps()
  KVM: arm64: Remove unused parameter in synchronize_vcpu_pstate()
  KVM: arm64: Remove extra argument for __pvkm_host_{share,unshare}_hyp()
  KVM: arm64: Inject UNDEF for a register trap without accessor
  KVM: arm64: Copy FGT traps to unprotected pKVM VCPU on VCPU load
  KVM: arm64: Fix EL2 S1 XN handling for hVHE setups
  KVM: arm64: gic: Check for vGICv3 when clearing TWI

Signed-off-by: Marc Zyngier <maz@kernel.org>
6 weeks agoKVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers
Will Deacon [Mon, 5 Jan 2026 15:49:09 +0000 (15:49 +0000)] 
KVM: arm64: Invert KVM_PGTABLE_WALK_HANDLE_FAULT to fix pKVM walkers

Commit ddcadb297ce5 ("KVM: arm64: Ignore EAGAIN for walks outside of a
fault") introduced a new walker flag ('KVM_PGTABLE_WALK_HANDLE_FAULT')
to KVM's page-table code. When set, the walk logic maintains its
previous behaviour of terminating a walk as soon as the visitor callback
returns an error. However, when the flag is clear, the walk will
continue if the visitor returns -EAGAIN and the error is then suppressed
and returned as zero to the caller.

Clearing the flag is beneficial when write-protecting a range of IPAs
with kvm_pgtable_stage2_wrprotect() but is not useful in any other
cases, either because we are operating on a single page (e.g.
kvm_pgtable_stage2_mkyoung() or kvm_phys_addr_ioremap()) or because the
early termination is desirable (e.g. when mapping pages from a fault in
user_mem_abort()).

Subsequently, commit e912efed485a ("KVM: arm64: Introduce the EL1 pKVM
MMU") hooked up pKVM's hypercall interface to the MMU code at EL1 but
failed to propagate any of the walker flags. As a result, page-table
walks at EL2 fail to set KVM_PGTABLE_WALK_HANDLE_FAULT even when the
early termination semantics are desirable on the fault handling path.

Rather than complicate the pKVM hypercall interface, invert the flag so
that the whole thing can be simplified and only pass the new flag
('KVM_PGTABLE_WALK_IGNORE_EAGAIN') from the wrprotect code.

Cc: Fuad Tabba <tabba@google.com>
Cc: Quentin Perret <qperret@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Fixes: fce886a60207 ("KVM: arm64: Plumb the pKVM MMU in KVM")
Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Quentin Perret <qperret@google.com>
Link: https://msgid.link/20260105154939.11041-2-will@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Don't blindly set set PSTATE.PAN on guest exit
Marc Zyngier [Wed, 7 Jan 2026 12:46:00 +0000 (12:46 +0000)] 
KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit

We set PSTATE.PAN to 1 on exiting from a guest if PAN support has
been compiled in and that it exists on the HW. However, this is not
necessarily correct.

In a nVHE configuration, there is no notion of PAN at EL2, so setting
PSTATE.PAN to anything is pointless.

Furthermore, not setting PAN to 0 when CONFIG_ARM64_PAN isn't set
means we run with the *guest's* PSTATE.PAN (which might be set to 1),
and we will explode on the next userspace access. Yes, the architecture
is delightful in that particular corner.

Fix the whole thing by always setting PAN to something when running
VHE (which implies PAN support), and only ignore it when running nVHE.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://msgid.link/20260107124600.2736328-1-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: nv: Respect stage-2 write permssion when setting stage-1 AF
Oliver Upton [Thu, 8 Jan 2026 20:42:30 +0000 (12:42 -0800)] 
KVM: arm64: nv: Respect stage-2 write permssion when setting stage-1 AF

Naturally, updating the Access Flag in a stage-1 descriptor requires
write permission at stage-2, although this isn't actually enforced in
KVM's software PTW.

Generate a stage-2 permission fault if the stage-1 walk attempts to
update the descriptor and its corresponding stage-2 translation lacks
write permission.

Fixes: bff8aa213dee ("KVM: arm64: Implement HW access flag management in stage-1 SW PTW")
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://msgid.link/20260108204230.677172-1-oupton@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Remove unused vcpu_{clear,set}_wfx_traps()
Dongxu Sun [Fri, 9 Jan 2026 08:02:26 +0000 (16:02 +0800)] 
KVM: arm64: Remove unused vcpu_{clear,set}_wfx_traps()

Function vcpu_{clear,set}_wfx_traps() are unused since
commit 0b5afe05377d7 ("KVM: arm64: Add early_param to
control WFx trapping").
Remove it.

Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Dongxu Sun <sundongxu1024@163.com>
Link: https://msgid.link/20260109080226.761107-1-sundongxu1024@163.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Remove unused parameter in synchronize_vcpu_pstate()
Alexandru Elisei [Tue, 16 Dec 2025 10:30:53 +0000 (10:30 +0000)] 
KVM: arm64: Remove unused parameter in synchronize_vcpu_pstate()

synchronize_vcpu_pstate() doesn't make use of the reference to exit_code,
remove the parameter.

Reviewed-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://msgid.link/20251216103053.47224-5-alexandru.elisei@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Remove extra argument for __pvkm_host_{share,unshare}_hyp()
Alexandru Elisei [Tue, 16 Dec 2025 10:30:52 +0000 (10:30 +0000)] 
KVM: arm64: Remove extra argument for __pvkm_host_{share,unshare}_hyp()

__pvkm_host_share_hyp() and __pkvm_host_unshare_hyp() both have one
parameter, the pfn, not two. Even though correctness isn't impacted because
the SMCCC handlers pass the first argument and ignore the second one, let's
call the functions with the proper number of arguments.

Reviewed-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Link: https://msgid.link/20251216103053.47224-4-alexandru.elisei@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Inject UNDEF for a register trap without accessor
Alexandru Elisei [Tue, 16 Dec 2025 10:30:51 +0000 (10:30 +0000)] 
KVM: arm64: Inject UNDEF for a register trap without accessor

Configuring a register trap without specifying an accessor function is
abviously a bug. Instead of calling die() when that happens, let's be a
bit more helpful and print the register encoding. Also inject an
undefined instruction exception in the guest, similar to other unhandled
register accesses.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://msgid.link/20251216103053.47224-3-alexandru.elisei@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Copy FGT traps to unprotected pKVM VCPU on VCPU load
Alexandru Elisei [Tue, 16 Dec 2025 10:30:50 +0000 (10:30 +0000)] 
KVM: arm64: Copy FGT traps to unprotected pKVM VCPU on VCPU load

Commit fb10ddf35c1c ("KVM: arm64: Compute per-vCPU FGTs at vcpu_load()")
introduced per-VCPU FGT traps. For an unprotected pKVM VCPU, the untrusted
host FGT configuration is copied in pkvm_vcpu_init_traps(), which is called
from __pkvm_init_vcpu(). __pkvm_init_vcpu() is called once per VCPU (when
the VCPU is first run) which means that the uninitialized, zero, values for
the FGT registers end up being used for the entire lifetime of the VCPU.
This causes both unwanted traps (for the inverse polarity trap bits) and
the guest being allowed to access registers it shouldn't.

Fix it by copying the FGT traps for unprotected pKVM VCPUs when the
untrusted host loads the VCPU.

Fixes: fb10ddf35c1c ("KVM: arm64: Compute per-vCPU FGTs at vcpu_load()")
Acked-by: Will Deacon <will@kernel.org>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://msgid.link/20251216103053.47224-2-alexandru.elisei@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: Fix EL2 S1 XN handling for hVHE setups
Marc Zyngier [Wed, 10 Dec 2025 17:30:19 +0000 (17:30 +0000)] 
KVM: arm64: Fix EL2 S1 XN handling for hVHE setups

The current XN implementation is tied to the EL2 translation regime,
and fall flat on its face with the EL2&0 one that is used for hVHE,
as the permission bit for privileged execution is a different one.

Fixes: 6537565fd9b7f ("KVM: arm64: Adjust EL2 stage-1 leaf AP bits when ARM64_KVM_HVHE is set")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Fuad Tabba <tabba@google.com>
Link: https://msgid.link/20251210173024.561160-2-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoKVM: arm64: gic: Check for vGICv3 when clearing TWI
Sascha Bischoff [Tue, 6 Jan 2026 16:52:10 +0000 (16:52 +0000)] 
KVM: arm64: gic: Check for vGICv3 when clearing TWI

Explicitly check for the vgic being v3 when disabling TWI. Failure to
check this can result in using the wrong view of the vgic CPU IF union
causing undesirable/unexpected behaviour.

Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://msgid.link/20260106165154.3321753-1-sascha.bischoff@arm.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
6 weeks agoarm64: Add support for TSV110 Spectre-BHB mitigation
Jinqian Yang [Sat, 27 Dec 2025 09:24:48 +0000 (17:24 +0800)] 
arm64: Add support for TSV110 Spectre-BHB mitigation

The TSV110 processor is vulnerable to the Spectre-BHB (Branch History
Buffer) attack, which can be exploited to leak information through
branch prediction side channels. This commit adds the MIDR of TSV110
to the list for software mitigation.

Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com>
Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev>
Signed-off-by: Will Deacon <will@kernel.org>
6 weeks agoLinux 6.19-rc4 v6.19-rc4
Linus Torvalds [Sun, 4 Jan 2026 22:41:55 +0000 (14:41 -0800)] 
Linux 6.19-rc4

6 weeks agoMerge tag 'core_urgent_for_v6.19_rc4' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 4 Jan 2026 15:21:18 +0000 (07:21 -0800)] 
Merge tag 'core_urgent_for_v6.19_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull core entry fix from Borislav Petkov:

 - Make sure clang inlines trivial local_irq_* helpers

* tag 'core_urgent_for_v6.19_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  entry: Always inline local_irq_{enable,disable}_exit_to_user()

7 weeks agoMerge tag 'pmdomain-v6.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh...
Linus Torvalds [Sat, 3 Jan 2026 17:18:36 +0000 (09:18 -0800)] 
Merge tag 'pmdomain-v6.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

Pull pmdomain fixes from Ulf Hansson:

 - mediatek: Fix spinlock recursion fix during probe

 - imx: Fix reference count leak during probe

* tag 'pmdomain-v6.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm:
  pmdomain: imx: Fix reference count leak in imx_gpc_probe()
  pmdomain: mtk-pm-domains: Fix spinlock recursion fix in probe

7 weeks agoMerge tag 'perf-tools-fixes-for-v6.19-2026-01-02' of git://git.kernel.org/pub/scm...
Linus Torvalds [Fri, 2 Jan 2026 22:24:09 +0000 (14:24 -0800)] 
Merge tag 'perf-tools-fixes-for-v6.19-2026-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools

Pull perf tool fixes and from Namhyung Kim:

 - skip building BPF skeletons if libopenssl is missing

 - a couple of test updates

 - handle error cases of filename__read_build_id()

 - support NVIDIA Olympus for ARM SPE profiling

 - update tool headers to sync with the kernel

* tag 'perf-tools-fixes-for-v6.19-2026-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools:
  tools build: Fix the common set of features test wrt libopenssl
  tools headers: Sync syscall table with kernel sources
  tools headers: Sync linux/socket.h with kernel sources
  tools headers: Sync linux/gfp_types.h with kernel sources
  tools headers: Sync arm64 headers with kernel sources
  tools headers: Sync x86 headers with kernel sources
  tools headers: Sync UAPI sound/asound.h with kernel sources
  tools headers: Sync UAPI linux/mount.h with kernel sources
  tools headers: Sync UAPI linux/fs.h with kernel sources
  tools headers: Sync UAPI linux/fcntl.h with kernel sources
  tools headers: Sync UAPI KVM headers with kernel sources
  tools headers: Sync UAPI drm/drm.h with kernel sources
  perf arm-spe: Add NVIDIA Olympus to neoverse list
  tools headers arm64: Add NVIDIA Olympus part
  perf tests top: Make the test exclusive
  perf tests kvm: Avoid leaving perf.data.guest file around
  perf symbol: Fix ENOENT case for filename__read_build_id
  perf tools: Disable BPF skeleton if no libopenssl found
  tools/build: Add a feature test for libopenssl

7 weeks agoMerge tag 'pm-6.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Linus Torvalds [Fri, 2 Jan 2026 20:35:29 +0000 (12:35 -0800)] 
Merge tag 'pm-6.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fix from Rafael Wysocki:
 "Fix a recent regression that affects system suspend testing
  at the 'core' level (Rafael Wysocki)"

* tag 'pm-6.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM: sleep: Fix suspend_test() at the TEST_CORE level

7 weeks agoMerge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Fri, 2 Jan 2026 20:28:24 +0000 (12:28 -0800)] 
Merge tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

Pull crypto library fix from Eric Biggers:
 "Fix the kunit_run_irq_test() function (which I recently added for the
  CRC and crypto tests) to be less timing-dependent.

  This fixes flakiness in the polyval kunit test suite"

* tag 'libcrypto-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:
  kunit: Enforce task execution in {soft,hard}irq contexts

7 weeks agoMerge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Linus Torvalds [Fri, 2 Jan 2026 20:25:47 +0000 (12:25 -0800)] 
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Pull rdma fixes from Jason Gunthorpe:

 - Fix several syzkaller found bugs:
    - Poor parsing of the RDMA_NL_LS_OP_IP_RESOLVE netlink
    - GID entry refcount leaking when CM destruction races with
      multicast establishment
    - Missing refcount put in ib_del_sub_device_and_put()

 - Fixup recently introduced uABI padding for 32 bit consistency

 - Avoid user triggered math overflow in MANA and AFA

 - Reading invalid netdev data during an event

 - kdoc fixes

 - Fix never-working gid copying in ib_get_gids_from_rdma_hdr

 - Typo in bnxt when validating the BAR

 - bnxt mis-parsed IB_SEND_IP_CSUM so it didn't work always

 - bnxt out of bounds access in bnxt related to the counters on new
   devices

 - Allocate the bnxt PDE table with the right sizing

 - Use dma_free_coherent() correctly in bnxt

 - Allow rxe to be unloadable when CONFIG_PROVE_LOCKING by adjusting the
   tracking of the global sockets it uses

 - Missing unlocking on error path in rxe

 - Compute the right number of pages in a MR in rtrs

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
  RDMA/bnxt_re: fix dma_free_coherent() pointer
  RDMA/rtrs: Fix clt_path::max_pages_per_mr calculation
  IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path
  RDMA/bnxt_re: Fix to use correct page size for PDE table
  RDMA/bnxt_re: Fix OOB write in bnxt_re_copy_err_stats()
  RDMA/bnxt_re: Fix IB_SEND_IP_CSUM handling in post_send
  RDMA/core: always drop device refcount in ib_del_sub_device_and_put()
  RDMA/rxe: let rxe_reclassify_recv_socket() call sk_owner_put()
  RDMA/bnxt_re: Fix incorrect BAR check in bnxt_qplib_map_creq_db()
  RDMA/core: Fix logic error in ib_get_gids_from_rdma_hdr()
  RDMA/efa: Remove possible negative shift
  RTRS/rtrs: clean up rtrs headers kernel-doc
  RDMA/irdma: avoid invalid read in irdma_net_event
  RDMA/mana_ib: check cqe length for kernel CQs
  RDMA/irdma: Fix irdma_alloc_ucontext_resp padding
  RDMA/ucma: Fix rdma_ucm_query_ib_service_resp struct padding
  RDMA/cm: Fix leaking the multicast GID table reference
  RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly

7 weeks agoMerge tag 'linux_kselftest-fixes-6.19-rc4' of git://git.kernel.org/pub/scm/linux...
Linus Torvalds [Fri, 2 Jan 2026 20:21:34 +0000 (12:21 -0800)] 
Merge tag 'linux_kselftest-fixes-6.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

Pull kselftest fixes from Shuah Khan:

 - Fix for build failures in tests that use an empty FIXTURE() seen in
   Android's build environment, which uses -D_FORTIFY_SOURCE=3, a build
   failure occurs in tests that use an empty FIXTURE()

 - Fix func_traceonoff_triggers.tc sometimes failures on Kunpeng-920
   board resulting from including transient trace file name in checksum
   compare

 - Fix to remove available_events requirement from toplevel-enable for
   instance as it isn't a valid requirement for this test

* tag 'linux_kselftest-fixes-6.19-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
  kselftest/harness: Use helper to avoid zero-size memset warning
  selftests/ftrace: Test toplevel-enable for instance
  selftests/ftrace: traceonoff_triggers: strip off names

7 weeks agoMerge tag 'block-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Fri, 2 Jan 2026 20:15:59 +0000 (12:15 -0800)] 
Merge tag 'block-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull block fixes from Jens Axboe:

 - Scan partition tables asynchronously for ublk, similarly to how nvme
   does it. This avoids potential deadlocks, which is why nvme does it
   that way too. Includes a set of selftests as well.

 - MD pull request via Yu:
     - Fix null-pointer dereference in raid5 sysfs group_thread_cnt
       store (Tuo Li)
     - Fix possible mempool corruption during raid1 raid_disks update
       via sysfs (FengWei Shih)
     - Fix logical_block_size configuration being overwritten during
       super_1_validate() (Li Nan)
     - Fix forward incompatibility with configurable logical block size:
       arrays assembled on new kernels could not be assembled on older
       kernels (v6.18 and before) due to non-zero reserved pad rejection
       (Li Nan)
     - Fix static checker warning about iterator not incremented (Li Nan)

 - Skip CPU offlining notifications on unmapped hardware queues

 - bfq-iosched block stats fix

 - Fix outdated comment in bfq-iosched

* tag 'block-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  block, bfq: update outdated comment
  blk-mq: skip CPU offline notify on unmapped hctx
  selftests/ublk: fix Makefile to rebuild on header changes
  selftests/ublk: add test for async partition scan
  ublk: scan partition in async way
  block,bfq: fix aux stat accumulation destination
  md: Fix forward incompatibility from configurable logical block size
  md: Fix logical_block_size configuration being overwritten
  md: suspend array while updating raid_disks via sysfs
  md/raid5: fix possible null-pointer dereferences in raid5_store_group_thread_cnt()
  md: Fix static checker warning in analyze_sbs

7 weeks agoMerge tag 'io_uring-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Fri, 2 Jan 2026 20:07:55 +0000 (12:07 -0800)] 
Merge tag 'io_uring-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull io_uring fixes from Jens Axboe:

 - Removed dead argument length for io_uring_validate_mmap_request()

 - Use GFP_NOWAIT for overflow CQEs on legacy ring setups rather than
   GFP_ATOMIC, which makes it play nicer with memcg limits

 - Fix a potential circular locking issue with tctx node removal and
   exec based cancelations

* tag 'io_uring-6.19-20260102' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/memmap: drop unused sz param in io_uring_validate_mmap_request()
  io_uring/tctx: add separate lock for list of tctx's in ctx
  io_uring: use GFP_NOWAIT for overflow CQEs on legacy rings

7 weeks agoMerge tag 'x86-urgent-2026-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Fri, 2 Jan 2026 20:04:51 +0000 (12:04 -0800)] 
Merge tag 'x86-urgent-2026-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 fix from Ingo Molnar:
 "Fix the AMD microcode Entrysign signature checking code to include
  more models"

* tag 'x86-urgent-2026-01-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/microcode/AMD: Fix Entrysign revision check for Zen5/Strix Halo

7 weeks agoMerge tag 'loongarch-fixes-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Fri, 2 Jan 2026 19:33:33 +0000 (11:33 -0800)] 
Merge tag 'loongarch-fixes-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson

Pull LoongArch fixes from Huacai Chen:
 "Complete CPUCFG registers definition, set correct protection_map[] for
  VM_NONE/VM_SHARED, fix some bugs in the orc stack unwinder, ftrace and
  BPF JIT"

* tag 'loongarch-fixes-6.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
  samples/ftrace: Adjust LoongArch register restore order in direct calls
  LoongArch: BPF: Enhance the bpf_arch_text_poke() function
  LoongArch: BPF: Enable trampoline-based tracing for module functions
  LoongArch: BPF: Adjust the jump offset of tail calls
  LoongArch: BPF: Save return address register ra to t0 before trampoline
  LoongArch: BPF: Zero-extend bpf_tail_call() index
  LoongArch: BPF: Sign extend kfunc call arguments
  LoongArch: Refactor register restoration in ftrace_common_return
  LoongArch: Enable exception fixup for specific ADE subcode
  LoongArch: Remove unnecessary checks for ORC unwinder
  LoongArch: Remove is_entry_func() and kernel_entry_end
  LoongArch: Use UNWIND_HINT_END_OF_STACK for entry points
  LoongArch: Set correct protection_map[] for VM_NONE/VM_SHARED
  LoongArch: Complete CPUCFG registers definition

7 weeks agoMerge tag 'drm-fixes-2026-01-02' of https://gitlab.freedesktop.org/drm/kernel
Linus Torvalds [Fri, 2 Jan 2026 17:53:45 +0000 (09:53 -0800)] 
Merge tag 'drm-fixes-2026-01-02' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "Happy New Year, jetlagged fixes from me, still pretty quiet, xe is
  most of this, with i915/nouveau/imagination fixes and some shmem
  cleanups.

  shmem:
   - docs and MODULE_LICENSE fix

  xe:
   - Ensure svm device memory is idle before migration completes
   - Fix a SVM debug printout
   - Use READ_ONCE() / WRITE_ONCE() for g2h_fence

  i915:
   - Fix eb_lookup_vmas() failure path

  nouveau:
   - fix prepare_fb warnings

  imagination:
   - prevent export of protected objects"

* tag 'drm-fixes-2026-01-02' of https://gitlab.freedesktop.org/drm/kernel:
  drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer
  drm/xe/guc: READ/WRITE_ONCE g2h_fence->done
  drm/pagemap, drm/xe: Ensure that the devmem allocation is idle before use
  drm/xe/svm: Fix a debug printout
  drm/gem-shmem: Fix the MODULE_LICENSE() string
  drm/gem-shmem: Fix typos in documentation
  drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb
  drm/imagination: Disallow exporting of PM/FW protected objects

7 weeks agoMerge tag 'v6.19-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd
Linus Torvalds [Fri, 2 Jan 2026 17:24:43 +0000 (09:24 -0800)] 
Merge tag 'v6.19-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd

Pull smb server fixes from Steve French:

 - Fix memory leak

 - Fix two refcount leaks

 - Fix error path in create_smb2_pipe

* tag 'v6.19-rc3-smb3-server-fixes' of git://git.samba.org/ksmbd:
  smb/server: fix refcount leak in smb2_open()
  smb/server: fix refcount leak in parse_durable_handle_context()
  smb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe()
  ksmbd: Fix memory leak in get_file_all_info()

7 weeks agoMerge tag 'v6.19-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Linus Torvalds [Fri, 2 Jan 2026 17:14:13 +0000 (09:14 -0800)] 
Merge tag 'v6.19-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6

Pull smb client fixes from Steve French:

 - Fix array out of bounds error in copy_file_range

 - Add tracepoint to help debug ioctl failures

* tag 'v6.19-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  smb: client: fix UBSAN array-index-out-of-bounds in smb2_copychunk_range
  smb3 client: add missing tracepoint for unsupported ioctls

7 weeks agoblock, bfq: update outdated comment
Julia Lawall [Wed, 31 Dec 2025 17:22:07 +0000 (18:22 +0100)] 
block, bfq: update outdated comment

The function bfq_bfqq_may_idle() was renamed as bfq_better_to_idle()
in commit 277a4a9b56cd ("block, bfq: give a better name to
bfq_bfqq_may_idle").  Update the comment accordingly.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
7 weeks agoio_uring/memmap: drop unused sz param in io_uring_validate_mmap_request()
Caleb Sander Mateos [Wed, 31 Dec 2025 18:19:06 +0000 (11:19 -0700)] 
io_uring/memmap: drop unused sz param in io_uring_validate_mmap_request()

io_uring_validate_mmap_request() doesn't use its size_t sz argument, so
remove it.

Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
7 weeks agoio_uring/tctx: add separate lock for list of tctx's in ctx
Jens Axboe [Wed, 31 Dec 2025 15:12:46 +0000 (08:12 -0700)] 
io_uring/tctx: add separate lock for list of tctx's in ctx

ctx->tcxt_list holds the tasks using this ring, and it's currently
protected by the normal ctx->uring_lock. However, this can cause a
circular locking issue, as reported by syzbot, where cancelations off
exec end up needing to remove an entry from this list:

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Tainted: G             L
------------------------------------------------------
syz.0.9999/12287 is trying to acquire lock:
ffff88805851c0a8 (&ctx->uring_lock){+.+.}-{4:4}, at: io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179

but task is already holding lock:
ffff88802db5a2e0 (&sig->cred_guard_mutex){+.+.}-{4:4}, at: prepare_bprm_creds fs/exec.c:1360 [inline]
ffff88802db5a2e0 (&sig->cred_guard_mutex){+.+.}-{4:4}, at: bprm_execve+0xb9/0x1400 fs/exec.c:1733

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&sig->cred_guard_mutex){+.+.}-{4:4}:
       __mutex_lock_common kernel/locking/mutex.c:614 [inline]
       __mutex_lock+0x187/0x1350 kernel/locking/mutex.c:776
       proc_pid_attr_write+0x547/0x630 fs/proc/base.c:2837
       vfs_write+0x27e/0xb30 fs/read_write.c:684
       ksys_write+0x145/0x250 fs/read_write.c:738
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #1 (sb_writers#3){.+.+}-{0:0}:
       percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
       percpu_down_read_freezable include/linux/percpu-rwsem.h:83 [inline]
       __sb_start_write include/linux/fs/super.h:19 [inline]
       sb_start_write+0x4d/0x1c0 include/linux/fs/super.h:125
       mnt_want_write+0x41/0x90 fs/namespace.c:499
       open_last_lookups fs/namei.c:4529 [inline]
       path_openat+0xadd/0x3dd0 fs/namei.c:4784
       do_filp_open+0x1fa/0x410 fs/namei.c:4814
       io_openat2+0x3e0/0x5c0 io_uring/openclose.c:143
       __io_issue_sqe+0x181/0x4b0 io_uring/io_uring.c:1792
       io_issue_sqe+0x165/0x1060 io_uring/io_uring.c:1815
       io_queue_sqe io_uring/io_uring.c:2042 [inline]
       io_submit_sqe io_uring/io_uring.c:2320 [inline]
       io_submit_sqes+0xbf4/0x2140 io_uring/io_uring.c:2434
       __do_sys_io_uring_enter io_uring/io_uring.c:3280 [inline]
       __se_sys_io_uring_enter+0x2e0/0x2b60 io_uring/io_uring.c:3219
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #0 (&ctx->uring_lock){+.+.}-{4:4}:
       check_prev_add kernel/locking/lockdep.c:3165 [inline]
       check_prevs_add kernel/locking/lockdep.c:3284 [inline]
       validate_chain kernel/locking/lockdep.c:3908 [inline]
       __lock_acquire+0x15a6/0x2cf0 kernel/locking/lockdep.c:5237
       lock_acquire+0x107/0x340 kernel/locking/lockdep.c:5868
       __mutex_lock_common kernel/locking/mutex.c:614 [inline]
       __mutex_lock+0x187/0x1350 kernel/locking/mutex.c:776
       io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
       io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
       io_uring_cancel_generic+0x6ca/0x7d0 io_uring/cancel.c:646
       io_uring_task_cancel include/linux/io_uring.h:24 [inline]
       begin_new_exec+0x10ed/0x2440 fs/exec.c:1131
       load_elf_binary+0x9f8/0x2d70 fs/binfmt_elf.c:1010
       search_binary_handler fs/exec.c:1669 [inline]
       exec_binprm fs/exec.c:1701 [inline]
       bprm_execve+0x92e/0x1400 fs/exec.c:1753
       do_execveat_common+0x510/0x6a0 fs/exec.c:1859
       do_execve fs/exec.c:1933 [inline]
       __do_sys_execve fs/exec.c:2009 [inline]
       __se_sys_execve fs/exec.c:2004 [inline]
       __x64_sys_execve+0x94/0xb0 fs/exec.c:2004
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

Chain exists of:
  &ctx->uring_lock --> sb_writers#3 --> &sig->cred_guard_mutex

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&sig->cred_guard_mutex);
                               lock(sb_writers#3);
                               lock(&sig->cred_guard_mutex);
  lock(&ctx->uring_lock);

 *** DEADLOCK ***

1 lock held by syz.0.9999/12287:
 #0: ffff88802db5a2e0 (&sig->cred_guard_mutex){+.+.}-{4:4}, at: prepare_bprm_creds fs/exec.c:1360 [inline]
 #0: ffff88802db5a2e0 (&sig->cred_guard_mutex){+.+.}-{4:4}, at: bprm_execve+0xb9/0x1400 fs/exec.c:1733

stack backtrace:
CPU: 0 UID: 0 PID: 12287 Comm: syz.0.9999 Tainted: G             L      syzkaller #0 PREEMPT(full)
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_circular_bug+0x2e2/0x300 kernel/locking/lockdep.c:2043
 check_noncircular+0x12e/0x150 kernel/locking/lockdep.c:2175
 check_prev_add kernel/locking/lockdep.c:3165 [inline]
 check_prevs_add kernel/locking/lockdep.c:3284 [inline]
 validate_chain kernel/locking/lockdep.c:3908 [inline]
 __lock_acquire+0x15a6/0x2cf0 kernel/locking/lockdep.c:5237
 lock_acquire+0x107/0x340 kernel/locking/lockdep.c:5868
 __mutex_lock_common kernel/locking/mutex.c:614 [inline]
 __mutex_lock+0x187/0x1350 kernel/locking/mutex.c:776
 io_uring_del_tctx_node+0xf0/0x2c0 io_uring/tctx.c:179
 io_uring_clean_tctx+0xd4/0x1a0 io_uring/tctx.c:195
 io_uring_cancel_generic+0x6ca/0x7d0 io_uring/cancel.c:646
 io_uring_task_cancel include/linux/io_uring.h:24 [inline]
 begin_new_exec+0x10ed/0x2440 fs/exec.c:1131
 load_elf_binary+0x9f8/0x2d70 fs/binfmt_elf.c:1010
 search_binary_handler fs/exec.c:1669 [inline]
 exec_binprm fs/exec.c:1701 [inline]
 bprm_execve+0x92e/0x1400 fs/exec.c:1753
 do_execveat_common+0x510/0x6a0 fs/exec.c:1859
 do_execve fs/exec.c:1933 [inline]
 __do_sys_execve fs/exec.c:2009 [inline]
 __se_sys_execve fs/exec.c:2004 [inline]
 __x64_sys_execve+0x94/0xb0 fs/exec.c:2004
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff3a8b8f749
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ff3a9a97038 EFLAGS: 00000246 ORIG_RAX: 000000000000003b
RAX: ffffffffffffffda RBX: 00007ff3a8de5fa0 RCX: 00007ff3a8b8f749
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000400
RBP: 00007ff3a8c13f91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ff3a8de6038 R14: 00007ff3a8de5fa0 R15: 00007ff3a8f0fa28
 </TASK>

Add a separate lock just for the tctx_list, tctx_lock. This can nest
under ->uring_lock, where necessary, and be used separately for list
manipulation. For the cancelation off exec side, this removes the
need to grab ->uring_lock, hence fixing the circular locking
dependency.

Reported-by: syzbot+b0e3b77ffaa8a4067ce5@syzkaller.appspotmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
7 weeks agoMerge tag 'drm-intel-fixes-2025-12-31' of https://gitlab.freedesktop.org/drm/i915...
Dave Airlie [Thu, 1 Jan 2026 06:55:35 +0000 (16:55 +1000)] 
Merge tag 'drm-intel-fixes-2025-12-31' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes

drm/i915 fixes for v6.19-rc4:
- Fix eb_lookup_vmas() failure path

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/4e79f041395bb8bcc9b2a76bb98b5e3df1c1c3eb@intel.com
7 weeks agoMerge tag 'drm-misc-fixes-2025-12-29' of https://gitlab.freedesktop.org/drm/misc...
Dave Airlie [Thu, 1 Jan 2026 06:51:30 +0000 (16:51 +1000)] 
Merge tag 'drm-misc-fixes-2025-12-29' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

drm-misc-fixes for v6.19-rc4:
- Documentation fixes and MODULE_LICENSE fix for shmem helper.
- Fix warnings in nouveau prepare_fb().
- Prevent export of protected objects in imagination driver.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/5506492b-02ca-47bc-8712-51e67f0e4b8b@linux.intel.com
7 weeks agoMerge tag 'drm-xe-fixes-2025-12-30' of https://gitlab.freedesktop.org/drm/xe/kernel...
Dave Airlie [Thu, 1 Jan 2026 06:39:19 +0000 (16:39 +1000)] 
Merge tag 'drm-xe-fixes-2025-12-30' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

Core Changes:
- Ensure a SVM device memory allocation is idle before migration complete (Thomas)

Driver Changes:
- Fix a SVM debug printout (Thomas)
- Use READ_ONCE() / WRITE_ONCE() for g2h_fence (Jonathan)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Link: https://patch.msgid.link/aVOTf6-whmkgrUuq@fedora
7 weeks agowifi: mt76: Remove blank line after mt792x firmware version dmesg
Shuah Khan [Wed, 31 Dec 2025 23:46:26 +0000 (16:46 -0700)] 
wifi: mt76: Remove blank line after mt792x firmware version dmesg

An extra blank line gets printed after printing firmware version
because the build date is null terminated. Remove the "\n" from
dev_info() calls to print firmware version and build date to fix
the problem.

Reported-by: Mario Limonciello <superm1@gmail.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
7 weeks agoRevert "wifi: mt76: Strip whitespace from build ddate"
Shuah Khan [Wed, 31 Dec 2025 03:56:42 +0000 (20:56 -0700)] 
Revert "wifi: mt76: Strip whitespace from build ddate"

This reverts commit f804a5895ebad2b2d4fb8a3688d2115926e993d5.

This change introduced the following panic, and mt792x_load_firmware()
fails. wifi is dead on systems with mt792x wireless.

kern  :crit  : kernel BUG at lib/string_helpers.c:1043!
kern  :warn  : Oops: invalid opcode: 0000 [#1] SMP NOPTI
kern  :warn  : CPU: 14 UID: 0 PID: 61 Comm: kworker/14:0 Tainted: G        W
        6.19.0-rc1 #1 PREEMPT(voluntary)
kern  :warn  : Tainted: [W]=WARN
kern  :warn  : Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.16 07/25/2025
kern  :warn  : Workqueue: events mt7921_init_work [mt7921_common]
kern  :warn  : RIP: 0010:__fortify_panic+0xd/0xf
kern  :warn  : Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 40 0f b6 ff e8 c3 55 71 00 <0f> 0b 48 8b 54 24 10 48 8b 74 24 08 4c 89 e9 48 c7 c7 00 a2 d5 a0
kern  :warn  : RSP: 0018:ffffa7a5c03a3d10 EFLAGS: 00010246
kern  :warn  : RAX: ffffffffa0d7aaf2 RBX: 0000000000000000 RCX: ffffffffa0d7aaf2
kern  :warn  : RDX: 0000000000000011 RSI: ffffffffa0d5a170 RDI: ffffffffa128db10
kern  :warn  : RBP: ffff91650ae52060 R08: 0000000000000010 R09: ffffa7a5c31b2000
kern  :warn  : R10: ffffa7a5c03a3bf0 R11: 00000000ffffffff R12: 0000000000000000
kern  :warn  : R13: ffffa7a5c31b2000 R14: 0000000000001000 R15: 0000000000000000
kern  :warn  : FS:  0000000000000000(0000) GS:ffff91743e664000(0000) knlGS:0000000000000000
kern  :warn  : CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kern  :warn  : CR2: 00007f10786c241c CR3: 00000003eca24000 CR4: 0000000000f50ef0
kern  :warn  : PKRU: 55555554
kern  :warn  : Call Trace:
kern  :warn  :  <TASK>
kern  :warn  :  mt76_connac2_load_patch.cold+0x2b/0xa41 [mt76_connac_lib]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  mt792x_load_firmware+0x36/0x150 [mt792x_lib]
kern  :warn  :  mt7921_run_firmware+0x2c/0x4a0 [mt7921_common]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  ? mt7921_rr+0x12/0x30 [mt7921e]
kern  :warn  :  ? srso_alias_return_thunk+0x5/0xfbef5
kern  :warn  :  ? ____mt76_poll_msec+0x75/0xb0 [mt76]
kern  :warn  :  mt7921e_mcu_init+0x4c/0x7a [mt7921e]
kern  :warn  :  mt7921_init_work+0x51/0x190 [mt7921_common]
kern  :warn  :  process_one_work+0x18b/0x340
kern  :warn  :  worker_thread+0x256/0x3a0
kern  :warn  :  ? __pfx_worker_thread+0x10/0x10
kern  :warn  :  kthread+0xfc/0x240
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ret_from_fork+0x254/0x290
kern  :warn  :  ? __pfx_kthread+0x10/0x10
kern  :warn  :  ret_from_fork_asm+0x1a/0x30
kern  :warn  :  </TASK>

Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
7 weeks agokselftest/harness: Use helper to avoid zero-size memset warning
Wake Liu [Wed, 24 Dec 2025 08:41:20 +0000 (16:41 +0800)] 
kselftest/harness: Use helper to avoid zero-size memset warning

When building kselftests with a toolchain that enables source
fortification (e.g., Android's build environment, which uses
-D_FORTIFY_SOURCE=3), a build failure occurs in tests that use an
empty FIXTURE().

The root cause is that an empty fixture struct results in
`sizeof(self_private)` evaluating to 0. The compiler's fortification
checks then detect the `memset()` call with a compile-time constant size
of 0, issuing a `-Wuser-defined-warnings` which is promoted to an error
by `-Werror`.

An initial attempt to guard the call with `if (sizeof(self_private) > 0)`
was insufficient. The compiler's static analysis is aggressive enough
to flag the `memset(..., 0)` pattern before evaluating the conditional,
thus still triggering the error.

To resolve this robustly, this change introduces a `static inline`
helper function, `__kselftest_memset_safe()`. This function wraps the
size check and the `memset()` call. By replacing the direct `memset()`
in the `__TEST_F_IMPL` macro with a call to this helper, we create an
abstraction boundary. This prevents the compiler's static analyzer from
"seeing" the problematic pattern at the macro expansion site, resolving
the build failure.

Build Context:
Compiler: Android (14488419, +pgo, +bolt, +lto, +mlgo, based on r584948) clang version 22.0.0 (https://android.googlesource.com/toolchain/llvm-project 2d65e4108033380e6fe8e08b1f1826cd2bfb0c99)
Relevant Options: -O2 -Wall -Werror -D_FORTIFY_SOURCE=3 -target i686-linux-android10000

Test: m kselftest_futex_futex_requeue_pi

Removed Gerrit Change-Id
Shuah Khan <skhan@linuxfoundation.org>

Link: https://lore.kernel.org/r/20251224084120.249417-1-wakel@google.com
Signed-off-by: Wake Liu <wakel@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
7 weeks agoMerge tag 'platform-drivers-x86-v6.19-2' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Wed, 31 Dec 2025 20:25:22 +0000 (12:25 -0800)] 
Merge tag 'platform-drivers-x86-v6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver fixes from Ilpo Järvinen:

 - alienware-wmi-wmax: Area-51, x16, and 16X Aurora laptops support

 - asus-armoury:
    - Fix FA507R PPT data
    - Add TDP data for more laptop models

 - asus-nb-wmi: Asus Zenbook 14 display toggle key support

 - dell-lis3lv02d: Dell Latitude 5400 support

 - hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing

 - ibm_rtl: Fix EBDA signature search pointer arithmetic

 - ideapad-laptop: Reassign KEY_CUT to KEY_SELECTIVE_SCREENSHOT

 - intel/pmt:
    - Fix kobject memory leak on init failure
    - Use valid pointers on error handling path

 - intel/vsec: Correct kernel doc comments

 - mellanox: mlxbf-pmc: Fix event names

 - msi-laptop: Add sysfs_remove_group()

 - samsumg-galaxybook: Do not cast pointer to a shorter type

 - think-lmi: WMI certificate thumbprint support for ThinkCenter

 - uniwill: Tuxedo Book BA15 Gen10 support

* tag 'platform-drivers-x86-v6.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (22 commits)
  platform/x86: asus-armoury: add support for G835LW
  platform/x86: asus-armoury: fix ppt data for FA507R
  platform/x86/intel/pmt/discovery: use valid device pointer in dev_err_probe
  platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing
  platform/x86: asus-armoury: add support for G615LR
  platform/x86: asus-armoury: add support for FA608UM
  platform/x86: asus-armoury: add support for GA403WR
  platform/x86: asus-armoury: add support for GU605CR
  platform/x86: ideapad-laptop: Reassign KEY_CUT to KEY_SELECTIVE_SCREENSHOT
  platform/x86: samsung-galaxybook: Fix problematic pointer cast
  platform/x86/intel/pmt: Fix kobject memory leak on init failure
  platform/x86/intel/vsec: correct kernel-doc comments
  platform/x86: ibm_rtl: fix EBDA signature search pointer arithmetic
  platform/x86: msi-laptop: add missing sysfs_remove_group()
  platform/x86: think-lmi: Add WMI certificate thumbprint support for ThinkCenter
  platform/x86: dell-lis3lv02d: Add Latitude 5400
  platform/mellanox: mlxbf-pmc: Remove trailing whitespaces from event names
  platform/x86: asus-nb-wmi: Add keymap for display toggle
  platform/x86/uniwill: Add TUXEDO Book BA15 Gen10
  platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora
  ...

7 weeks agoselftests/ftrace: Test toplevel-enable for instance
Zheng Yejian [Tue, 9 May 2023 20:36:59 +0000 (04:36 +0800)] 
selftests/ftrace: Test toplevel-enable for instance

'available_events' is actually not required by
'test.d/event/toplevel-enable.tc' and its Existence has been tested in
'test.d/00basic/basic4.tc'.

So the require of 'available_events' can be dropped and then we can add
'instance' flag to test 'test.d/event/toplevel-enable.tc' for instance.

Test result show as below:
 # ./ftracetest test.d/event/toplevel-enable.tc
 === Ftrace unit tests ===
 [1] event tracing - enable/disable with top level files [PASS]
 [2] (instance)  event tracing - enable/disable with top level files [PASS]

 # of passed:  2
 # of failed:  0
 # of unresolved:  0
 # of untested:  0
 # of unsupported:  0
 # of xfailed:  0
 # of undefined(test bug):  0

Link: https://lore.kernel.org/r/20230509203659.1173917-1-zhengyejian1@huawei.com
Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>