aboutsummaryrefslogtreecommitdiffstats
path: root/arch (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-17arm64: dts: qcom: Add HAMOA-IOT-SOM platformYijie Yang1-0/+619
The HAMOA-IOT-SOM is a compact computing module that integrates a System on Chip (SoC) — specifically the x1e80100 — along with essential components optimized for IoT applications. It is designed to be mounted on carrier boards, enabling the development of complete embedded systems. Make the following peripherals on the SOM enabled: - Regulators on the SOM - Reserved memory regions - PCIe6a and its PHY - PCIe4 and its PHY - USB0 through USB6 and their PHYs - ADSP, CDSP - Graphic - Video Written in collaboration with Yingying Tang (PCIe4) <quic_yintang@quicinc.com> and Wangao Wang (Video) <quic_wangaow@quicinc.com>. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250917-hamoa_initial-v12-2-4ed39d17dfc5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17riscv: mm: Return intended SATP mode for noXlvl optionsJunhui Liu2-4/+4
Change the return value of match_noXlvl() to return the SATP mode that will be used, rather than the mode being disabled. This enables unified logic for return value judgement with the function that obtains mmu-type from the fdt, avoiding extra conversion. This only changes the naming, with no functional impact. Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/20250722-satp-from-fdt-v1-1-5ba22218fa5f@pigmoral.tech Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-17arm64: dts: qcom: sm8750-mtp: Add WiFi and BluetoothKrzysztof Kozlowski1-4/+143
MTP8750 rev 2.0 (power grid v8) boards come as two different variants with different WiFi chips: WCN7850 and WCN786x. WCN7850 is already supported by the kernel, but WCN786x is not. Both of the board variants are considered newest revisions and the difference is only in MCN numbers and internal codenames. Add WCN7850 WiFi and Bluetooth to the MTP8750, stating that this DTS represents the WCN7850 variant. The S4D and S5F regulators should operate at 0.85 V, thus adjust lower constraint and regulator name. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250902140018.247209-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17arm64: dts: qcom: msm8953-xiaomi-daisy: fix cd-gpiosBarnabás Czémán1-1/+1
SD detection was not working because cd-gpios flag was wrongly configured, according to downstream sources device is using GPIO_ACTIVE_HIGH. Fix SD detection with change cd-gpios from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH. Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite") Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250903-daisy-sd-fix-v2-1-e08c50f3be57@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free()Hengqi Chen1-2/+1
The current implementation seems incorrect and does NOT match the comment above, use bpf_jit_binary_pack_finalize() instead. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20250916232653.101004-1-hengqi.chen@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-17Merge tag 'kvm-s390-master-6.17-1' of ↵Paolo Bonzini3-21/+34
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD - KVM mm fixes - Postcopy fix
2025-09-17Merge tag 'kvm-x86-fixes-6.17-rcN' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini1-2/+1
KVM x86 fix for 6.17-rcN Sync the vTPR from the local APIC to the VMCB even when AVIC is active, to fix a bug where host updates to the vTPR, e.g. via KVM_SET_LAPIC or emulation of a guest access, effectively get lost and result in interrupt delivery issues in the guest.
2025-09-17Merge tag 'kvmarm-fixes-6.17-2' of ↵Paolo Bonzini18-151/+114
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 6.17, round #3 - Invalidate nested MMUs upon freeing the PGD to avoid WARNs when visiting from an MMU notifier - Fixes to the TLB match process and TLB invalidation range for managing the VCNR pseudo-TLB - Prevent SPE from erroneously profiling guests due to UNKNOWN reset values in PMSCR_EL1 - Fix save/restore of host MDCR_EL2 to account for eagerly programming at vcpu_load() on VHE systems - Correct lock ordering when dealing with VGIC LPIs, avoiding scenarios where an xarray's spinlock was nested with a *raw* spinlock - Permit stage-2 read permission aborts which are possible in the case of NV depending on the guest hypervisor's stage-2 translation - Call raw_spin_unlock() instead of the internal spinlock API - Fix parameter ordering when assigning VBAR_EL1
2025-09-17KVM: arm64: Use ARM64_HAS_GICV5_LEGACY for GICv5 probingSascha Bischoff1-1/+1
The previous implementation of the probing function had the flaw that it wouldn't catch mismatched CPU features. Specifically, GICv5 legacy support (support for GICv3 VMs on a GICv5 host) was being enabled as long as the initial boot CPU had support for the feature. This allowed the support to become enabled on mismatched configurations. Move to using cpus_have_final_cap(ARM64_HAS_GICV5_LEGACY) instead, which only returns true when all booted CPUs support FEAT_GCIE_LEGACY. A byproduct of this is that it ensures that late onlining of CPUs is blocked on feature mismatch. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17arm64: cpucaps: Add GICv5 Legacy vCPU interface (GCIE_LEGACY) capabilitySascha Bischoff2-0/+16
Implement the GCIE_LEGACY capability as a system feature to be able to check for support from KVM. The type is explicitly ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, which means that the capability is enabled early if all boot CPUs support it. Additionally, if this capability is enabled during boot, it prevents late onlining of CPUs that lack it, thereby avoiding potential mismatched configurations which would break KVM. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Enable nested for GICv5 host with FEAT_GCIE_LEGACYSascha Bischoff1-2/+3
Extend the NV check to pass for a GICv5 host that has FEAT_GCIE_LEGACY. The has_gcie_v3_compat flag is only set on GICv5 hosts (that explicitly support FEAT_GCIE_LEGACY), and hence the explicit check for a VGIC_V5 is omitted. As of this change, vGICv3-based VMs can run with nested on a compatible GICv5 host. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Don't access ICC_SRE_EL2 if GICv3 doesn't support v2 compatibilityMarc Zyngier3-16/+20
We currently access ICC_SRE_EL2 at each load/put on VHE, and on each entry/exit on nVHE. Both are quite onerous on NV, as this register always traps. We do this to make sure the EL1 guest doesn't flip between v2 and v3 behind our back. But all modern implementations have dropped v2, and this is just overhead. At the same time, the GICv5 spec has been fixed to allow access to ICC_SRE_EL2 in legacy mode. Use this opportunity to replace the GICv5 checks for v2 compat checks, with an ad-hoc static key. Co-developed-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Fix page leak in user_mem_abort()Fuad Tabba1-2/+7
The user_mem_abort() function acquires a page reference via __kvm_faultin_pfn() early in its execution. However, the subsequent checks for mismatched attributes between stage 1 and stage 2 mappings would return an error code directly, bypassing the corresponding page release. Fix this by storing the error and releasing the unused page before returning the error. Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings") Fixes: 2a8dfab26677 ("KVM: arm64: Block cacheable PFNMAP mapping") Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2025-09-17Merge branch kvm-arm64/dump-instr into kvmarm-master/nextMarc Zyngier4-8/+23
* kvm-arm64/dump-instr: : . : Dump the isntruction stream on panic, just like the rest of the kernel : already does. : : Patches courtesy of Mostafa Saleh (20250909133631.3844423-1-smostafa@google.com) : . KVM: arm64: Map hyp text as RO and dump instr on panic KVM: arm64: Dump instruction on hyp panic Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17Merge branch kvm-arm64/mmio-rcu into kvmarm-master/nextMarc Zyngier2-11/+10
* kvm-arm64/mmio-rcu: : . : Speed up MMIO registration by avoiding unnecessary RCU synchronisation, : courtesy of Keir Fraser (20250909100007.3136249-1-keirf@google.com). : . KVM: Avoid synchronize_srcu() in kvm_io_bus_register_dev() KVM: Implement barriers before accessing kvm->buses[] on SRCU read paths KVM: arm64: vgic: Explicitly implement vgic_dist::ready ordering KVM: arm64: vgic-init: Remove vgic_ready() macro Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Fix kvm_vcpu_{set,is}_be() to deal with EL2 stateMarc Zyngier1-6/+14
Nobody really cares about BE, but KVM currently only deals with SCTLR_EL1 when evaluating or setting the endianness in PSCI, meaning that we evaluate whatever the L2 state has been at some point. Teach these primitives about SCTLR_EL2, and forget about BE... Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17arm64: dts: qcom: ipq5018: add QUP1 UART2 nodeManikanta Mylavarapu1-0/+10
Add node to support the second UART node controller in IPQ5018. Signed-off-by: Manikanta Mylavarapu <quic_mmanikan@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20250917-ipq5018-uart2-v1-1-f8680bbf947f@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17arm64: dts: qcom: lemans: Flatten usb controller nodesKrishna Kurapati3-73/+44
Flatten usb controller nodes and update to using latest bindings and flattened driver approach. Enumeration of ADB has been tested on EVK Platform. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250917123827.671966-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17x86/sev: Add new dump_rmp parameter to snp_leak_pages() APIAshish Kalra2-4/+10
When leaking certain page types, such as Hypervisor Fixed (HV_FIXED) pages, it does not make sense to dump RMP contents for the 2MB range of the page(s) being leaked. In the case of HV_FIXED pages, this is not an error situation where the surrounding 2MB page RMP entries can provide debug information. Add new __snp_leak_pages() API with dump_rmp bool parameter to support continue adding pages to the snp_leaked_pages_list but not issue dump_rmpentry(). Make snp_leak_pages() a wrapper for the common case which also allows existing users to continue to dump RMP entries. Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/cover.1758057691.git.ashish.kalra@amd.com
2025-09-17x86/cpu/topology: Define AMD64_CPUID_EXT_FEAT MSRK Prateek Nayak2-3/+9
Add defines for the 0xc001_1005 MSR (Core::X86::Msr::CPUID_ExtFeatures) used to toggle the extended CPUID features, instead of using literal numbers. Also define and use the bits necessary for an old TOPOEXT fixup on AMD Family 0x15 processors. No functional changes intended. [ bp: Massage, rename MSR to adhere to the documentation name. ] Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/20250901170418.4314-1-kprateek.nayak@amd.com
2025-09-17x86/cpu/topology: Check for X86_FEATURE_XTOPOLOGY instead of passing ↵K Prateek Nayak1-11/+8
has_xtopology cpu_parse_topology_ext() sets X86_FEATURE_XTOPOLOGY before returning true if any of the XTOPOLOGY leaf (0x80000026 / 0xb) could be parsed successfully. Instead of storing and passing around this return value using "has_xtopology" in parse_topology_amd(), check for X86_FEATURE_XTOPOLOGY directly in parse_8000_001e() to simplify the flow. No functional changes intended. Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/20250901170418.4314-1-kprateek.nayak@amd.com
2025-09-17x86/cpu/cacheinfo: Simplify cacheinfo_amd_init_llc_id() using _cpuid4_infoK Prateek Nayak1-27/+21
struct _cpuid4_info has the same layout as the CPUID leaf 0x8000001d. Use the encoded definition and amd_fill_cpuid4_info(), get_cache_id() helpers instead of open coding masks and shifts to calculate the llc_id. cacheinfo_amd_init_llc_id() is only called on AMD systems that support X86_FEATURE_TOPOEXT and amd_fill_cpuid4_info() uses the information from CPUID leaf 0x8000001d on all these systems which is consistent with the current open coded implementation. While at it, avoid reading cpu_data() every time get_cache_id() is called and instead pass the APIC ID necessary to return the _cpuid4_info.id from get_cache_id(). No functional changes intended. [ bp: do what Ahmed suggests: merge into one patch, make id4 ptr const. ] Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Ahmed S. Darwish <darwi@linutronix.de> Link: https://lore.kernel.org/20250821051910.7351-2-kprateek.nayak@amd.com
2025-09-17x86/cpu: Rename and move CPU model entry for Diamond RapidsTony Luck1-4/+3
This model was added as INTEL_PANTHERCOVE_X (based on the name of the core) with a comment that the platform name is Diamond Rapids. It was also placed at the end of the file in a new section for family 19 processors. This is different from previous naming as Andrew Cooper noted. PeterZ agreed and posted a patch[1] to fix the name and move it in sequence with other Xeon servers. But without a commit description or sign-off the patch wasn't ever applied. Patch updated to cover one additional use of the #define by turbostat and to change the "Family 6" comment to also list 18 and 19 since new models in these families are mixed in with family 6. Originally-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Link: https://lore.kernel.org/all/20250214130205.GK14028@noisy.programming.kicks-ass.net/ # [1]
2025-09-17dts: sophgo: sg2042: added numa id descriptionHan Gao2-0/+84
According to the description of [1], sg2042 is divided into 4 numa. STREAM test performance will improve. Before: Function Best Rate MB/s Avg time Min time Max time Copy: 10739.7 0.015687 0.014898 0.016385 Scale: 10865.9 0.015628 0.014725 0.016757 Add: 10622.3 0.023276 0.022594 0.023899 Triad: 10583.4 0.023653 0.022677 0.024761 After: Function Best Rate MB/s Avg time Min time Max time Copy: 34254.9 0.005142 0.004671 0.005995 Scale: 37735.5 0.004752 0.004240 0.005407 Add: 44206.8 0.005983 0.005429 0.006461 Triad: 43040.6 0.006320 0.005576 0.006996 [1] https://github.com/sophgo/sophgo-doc/blob/main/SG2042/TRM/source/pic/mesh.png Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/20250910105531.519897-1-rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-09-17riscv: Use generic TIF bitsThomas Gleixner2-18/+14
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by RISCV. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-09-17loongarch: Use generic TIF bitsThomas Gleixner2-42/+35
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by loongarch. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-09-17s390/entry: Remove unused TIF flagsSven Schnelle1-10/+0
The conversion of s390 to generic entry missed to remove the TIF_SYSCALL*/TIF_SECCOMP flags. Remove them as they are unused now. Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com>
2025-09-17s390: Use generic TIF bitsThomas Gleixner2-26/+19
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by s390. So no further action required here. This leaves a comment about the AUDIT/TRACE/SECCOMP bits which are handled by SYSCALL_WORK in the generic code, so they seem redundant, but that's a problem for the s390 wizards to think about. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com>
2025-09-17x86: Use generic TIF bitsThomas Gleixner2-45/+32
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by x86. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
2025-09-17asm-generic: Provide generic TIF infrastructureThomas Gleixner1-0/+4
Common TIF bits do not have to be defined by every architecture. They can be defined in a generic header. That allows adding generic TIF bits without chasing a gazillion of architecture headers, which is again a unjustified burden on anyone who works on generic infrastructure as it always needs a boat load of work to keep existing architecture code working when adding new stuff. While it is not as horrible as the ignorance of the generic entry infrastructure, it is a welcome mechanism to make architecture people rethink their approach of just leaching generic improvements into architecture code and thereby making it accumulatingly harder to maintain and improve generic code. It's about time that this changes. Provide the infrastructure and split the TIF space in half, 16 generic and 16 architecture specific bits. This could probably be extended by TIF_SINGLESTEP and BLOCKSTEP, but those are only used in architecture specific code. So leave them alone for now. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_ITYPE_IMMNam Cao1-1/+1
Use RV_EXTRACT_ITYPE_IMM, instead of re-implementing it in simulate_jalr(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8ae34e966c312ae5cf6c09a35ddc290cce942208.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_UTYPE_IMMNam Cao1-12/+1
Use RV_EXTRACT_UTYPE_IMM, instead of reimplementing it in simulate_auipc(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8f0defce9f1f23f1b44bb9750ed083cfc124213c.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_RD_REGNam Cao1-6/+3
Use RV_EXTRACT_RD_REG, instead of reimplementing its code. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b31e5b41df5839a76103348e54dc034c8a43447a.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_BTYPE_IMMNam Cao1-9/+3
Use RVC_EXTRACT_BTYPE_IMM, instead of reimplementing it in simulate_c_bnez_beqz(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8a8ed970f279fa5f24c90d840c2130e37bc6d16e.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_C2_RS1_REGNam Cao1-1/+1
Use RVC_EXTRACT_C2_RS1_REG, instead of reimplementing it in simulate_c_jr_jalr(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/d56955cd683411c6d2f63d13c78e0572462a3269.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_JTYPE_IMMNam Cao1-17/+2
Use RVC_EXTRACT_JTYPE_IMM, instead of reimplementing it in simulate_c_j(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/24497deaab06d6b12cb84923606ec26f67e25424.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: fixed subject line typo] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_BTYPE_IMMNam Cao1-10/+1
Use RV_EXTRACT_BTYPE_IMM, instead of reimplementing it in simulate_branch(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b441038c991da11a7a48ea7140ab00e3bb119387.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_RS1_REGNam Cao1-5/+2
Use RV_EXTRACT_RS1_REG instead of reimplementing its code. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b441038c991da11a7a48ea7140ab00e3bb119387.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_JTYPE_IMMNam Cao1-6/+3
Use RV_EXTRACT_JTYPE_IMM, instead of reimplementing it in simulate_jal(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/af502036738d381c6bdb96a236d21bab8c343f74.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Move branch_funct3 to insn.hNam Cao2-4/+6
Similar to other instruction-processing macros/functions, branch_funct3 should be in insn.h. Move it into insn.h as RV_EXTRACT_FUNCT3. This new name matches the style in insn.h. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/200c29a26338f19d09963fa02562787e8cfa06f2.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: updated to use RV_X_MASK and to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Move branch_rs2_idx to insn.hNam Cao2-4/+6
Similar to other instruction-processing macros/functions, branch_rs2_idx should be in insn.h. Move it into insn.h as RV_EXTRACT_RS2_REG. This new name matches the style in insn.h. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/107d4a6c1818bf169be2407b273a0483e6d55bbb.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: updated to use RV_X_MASK and to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Move all duplicate insn parsing macros into asm/insn.hAlexandre Ghiti3-273/+166
kernel/traps_misaligned.c and kvm/vcpu_insn.c define the same macros to extract information from the instructions. Let's move the definitions into asm/insn.h to avoid this duplication. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-3-d865dc9ad180@rivosinc.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Strengthen duplicate and inconsistent definition of RV_X()Alexandre Ghiti4-22/+23
RV_X() macro is defined in two different ways which is error prone. So harmonize its first definition and add another macro RV_X_MASK() for the second one. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-2-d865dc9ad180@rivosinc.com [pjw@kernel.org: upcase the macro name to conform with previous practice] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Fix typo EXRACT -> EXTRACTAlexandre Ghiti2-2/+2
Simply fix a typo. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-1-d865dc9ad180@rivosinc.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Add kprobes KUnit testNam Cao6-0/+323
Add KUnit test for riscv kprobes, mostly for simulated instructions. The test install kprobes into multiple sample functions, and check that these functions still return the expected magic value. This test can detect some kprobe bugs reported in the past (in Link:). Link: https://lore.kernel.org/linux-riscv/20241119111056.2554419-1-namcao@linutronix.de/ Link: https://lore.kernel.org/stable/c7e463c0-8cad-4f4e-addd-195c06b7b6de@iscas.ac.cn/ Link: https://lore.kernel.org/linux-riscv/20230829182500.61875-1-namcaov@gmail.com/ Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250513151631.3520793-1-namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headersThomas Huth31-71/+71
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize on the __ASSEMBLER__ macro that is provided by the compilers now. This originally was a completely mechanical patch (done with a simple "sed -i" statement), with some manual fixups during rebasing of the patch later. Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: linux-riscv@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250606070952.498274-3-thuth@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headersThomas Huth3-5/+5
__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. This is a completely mechanical patch (done with a simple "sed -i" statement). Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: linux-riscv@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250606070952.498274-2-thuth@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: introduce ioremap_wc()Yunhui Cui2-0/+5
Compared with IO attributes, NC attributes can improve performance, specifically in these aspects: Relaxed Order, Gathering, Supports Read Speculation, Supports Unaligned Access. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250722091504.45974-2-cuiyunhui@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16arm64: Kconfig: Remove GCS restrictions on UPROBESJeremy Linton1-1/+0
Now that the uprobe paths have been made GCS compatible drop the Kconfig restriction. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: uprobes: Add GCS support to uretprobesJeremy Linton1-0/+33
Ret probes work by changing the value in the link register at the probe location to return to the probe rather than the calling routine. Thus the GCS needs to be updated with this address as well. Since its possible to insert probes at locations where the current value of the LR doesn't match the GCS state this needs to be detected and handled in order to maintain the existing no-fault behavior. Co-developed-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> [will: Add '__force' to gcspr casts in arch_uretprobe_hijack_return_addr()] Signed-off-by: Will Deacon <will@kernel.org>