summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-05-07arm64: dts: qcom: msm8916/39: Move UART pinctrl to board filesStephan Gerhold28-12/+87
In preparation of adding a new console UART specific pinctrl template, move the pinctrl reference to the board DT part. This forces people porting new boards to consider what exactly they need for their board. No functional change for the boards upstream. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250422-msm8916-console-pinctrl-v2-1-f345b7a53c91@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: x1e80100: Fix PCIe 3rd controller DBI sizeAbel Vesa1-1/+1
According to documentation, the DBI range size is 0xf20. So fix it. Cc: stable@vger.kernel.org # 6.14 Fixes: f8af195beeb0 ("arm64: dts: qcom: x1e80100: Add support for PCIe3 on x1e80100") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250422-x1e80100-dts-fix-pcie3-dbi-size-v1-1-c197701fd7e4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: x1e/x1p: Add EL2 overlay for WoA devicesNikita Travkin3-13/+77
WoA devices using x1e/x1p use android firmware to boot, which notably includes Gunyah hypervisor. This means that, so far, Linux-based OS could only boot in EL1 on those devices. However Windows can replace Gunyah upon boot with it's own hypervisor, and with the use of tools such as "slbounce", it's possible to do the same for Linux-based OS, in which case some modifications to the DT are necessary to facilitate the absence of Gunyah services. Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to create -el2.dtb for each of them alongside "normal" dtb. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-5-24e9b4572e15@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: x1e80100: Add PCIe IOMMUNikita Travkin1-0/+14
x1e80100 has an SMMUv3 connected to PCIe which is normally controlled by Gunyah and is thus transparent to the OS. However if we boot Linux in EL2, without Gunyah, we need to manage this IOMMU ourselves. To make that easier, and since the hardware actually exists, just not "usually" managed by Linux, describe it in the dts as "reserved". Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-4-24e9b4572e15@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: sc8280xp: Add EL2 overlay for WoA devicesNikita Travkin2-5/+54
WoA devices using sc8280xp use android firmware to boot, which notably includes QHEE hypervisor. This means that, so far, Linux-based OS could only boot in EL1 on those devices. However Windows can replace QHEE upon boot with it's own hypervisor, and with the use of tools such as "slbounce", it's possible to do the same for Linux-based OS, in which case some modifications to the DT are necessary to facilitate the absence of QHEE services. Add a EL2-specific DT overlay and apply it to sc8280xp WoA devices to create -el2.dtb for each of them alongside "normal" dtb. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-3-24e9b4572e15@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: sc8280xp: Add PCIe IOMMUNikita Travkin1-0/+14
sc8280xp has an SMMUv3 connected to PCIe which is normally controlled by QHEE and is thus transparent to the OS. However if we boot Linux in EL2, without QHEE, we need to manage this IOMMU ourselves. To make that easier, and since the hardware actually exists, just not "usually" managed by Linux, describe it in the dts as "reserved". Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-2-24e9b4572e15@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07arm64: dts: qcom: sc7180: Add EL2 overlay for WoA devicesNikita Travkin2-1/+24
WoA devices using sc7180 use android firmware to boot, which notably includes QHEE hypervisor. This means that, so far, Linux-based OS could only boot in EL1 on those devices. However Windows can replace QHEE upon boot with it's own hypervisor, and with the use of tools such as "slbounce", it's possible to do the same for Linux-based OS, in which case some modifications to the DT are necessary to facilitate the absence of QHEE services. Add a EL2-specific DT overlay and apply it to sc7180 WoA devices to create -el2.dtb for each of them alongside "normal" dtb. Signed-off-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-1-24e9b4572e15@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST or Rust >= 1.88Paweł Anikiel1-0/+1
Calling core::fmt::write() from rust code while FineIBT is enabled results in a kernel panic: [ 4614.199779] kernel BUG at arch/x86/kernel/cet.c:132! [ 4614.205343] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 4614.211781] CPU: 2 UID: 0 PID: 6057 Comm: dmabuf_dump Tainted: G U O 6.12.17-android16-0-g6ab38c534a43 #1 9da040f27673ec3945e23b998a0f8bd64c846599 [ 4614.227832] Tainted: [U]=USER, [O]=OOT_MODULE [ 4614.241247] RIP: 0010:do_kernel_cp_fault+0xea/0xf0 ... [ 4614.398144] RIP: 0010:_RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x0/0x20 [ 4614.407792] Code: 48 f7 df 48 0f 48 f9 48 89 f2 89 c6 5d e9 18 fd ff ff 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 41 81 ea 14 61 af 2c 74 03 0f 0b 90 <66> 0f 1f 00 55 48 89 e5 48 89 f2 48 8b 3f be 01 00 00 00 5d e9 e7 [ 4614.428775] RSP: 0018:ffffb95acfa4ba68 EFLAGS: 00010246 [ 4614.434609] RAX: 0000000000000000 RBX: 0000000000000010 RCX: 0000000000000000 [ 4614.442587] RDX: 0000000000000007 RSI: ffffb95acfa4ba70 RDI: ffffb95acfa4bc88 [ 4614.450557] RBP: ffffb95acfa4bae0 R08: ffff0a00ffffff05 R09: 0000000000000070 [ 4614.458527] R10: 0000000000000000 R11: ffffffffab67eaf0 R12: ffffb95acfa4bcc8 [ 4614.466493] R13: ffffffffac5d50f0 R14: 0000000000000000 R15: 0000000000000000 [ 4614.474473] ? __cfi__RNvXs5_NtNtNtCs3o2tGsuHyou_4core3fmt3num3impyNtB9_7Display3fmt+0x10/0x10 [ 4614.484118] ? _RNvNtCs3o2tGsuHyou_4core3fmt5write+0x1d2/0x250 This happens because core::fmt::write() calls core::fmt::rt::Argument::fmt(), which currently has CFI disabled: library/core/src/fmt/rt.rs: 171 // FIXME: Transmuting formatter in new and indirectly branching to/calling 172 // it here is an explicit CFI violation. 173 #[allow(inline_no_sanitize)] 174 #[no_sanitize(cfi, kcfi)] 175 #[inline] 176 pub(super) unsafe fn fmt(&self, f: &mut Formatter<'_>) -> Result { This causes a Control Protection exception, because FineIBT has sealed off the original function's endbr64. This makes rust currently incompatible with FineIBT. Add a Kconfig dependency that prevents FineIBT from getting turned on by default if rust is enabled. [ Rust 1.88.0 (scheduled for 2025-06-26) should have this fixed [1], and thus we relaxed the condition with Rust >= 1.88. When `objtool` lands checking for this with e.g. [2], the plan is to ideally run that in upstream Rust's CI to prevent regressions early [3], since we do not control `core`'s source code. Alice tested the Rust PR backported to an older compiler. Peter would like that Rust provides a stable `core` which can be pulled into the kernel: "Relying on that much out of tree code is 'unfortunate'". - Miguel ] Signed-off-by: Paweł Anikiel <panikiel@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Link: https://github.com/rust-lang/rust/pull/139632 [1] Link: https://lore.kernel.org/rust-for-linux/20250410154556.GB9003@noisy.programming.kicks-ass.net/ [2] Link: https://github.com/rust-lang/rust/pull/139632#issuecomment-2801950873 [3] Link: https://lore.kernel.org/r/20250410115420.366349-1-panikiel@google.com Link: https://lore.kernel.org/r/att0-CANiq72kjDM0cKALVy4POEzhfdT4nO7tqz0Pm7xM+3=_0+L1t=A@mail.gmail.com [ Reduced splat. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-05-06arm64: dts: qcom: x1e001de-devkit: Fix pin config for USB0 retimer vregsAbel Vesa1-0/+12
Describe the missing power source, bias and direction for each of the USB0 retimer gpio-controlled voltage regulators related pin configuration. Fixes: 019e1ee32fec ("arm64: dts: qcom: x1e001de-devkit: Enable external DP support") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250422-x1e001de-devkit-dts-fix-retimer-gpios-v2-2-0129c4f2b6d7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e001de-devkit: Describe USB retimers resets pin configsAbel Vesa1-0/+32
Currently, on the X Elite Devkit, the pin configuration of the reset gpios for all three PS8830 USB retimers are left configured by the bootloader. Fix that by describing their pin configuration. Fixes: 019e1ee32fec ("arm64: dts: qcom: x1e001de-devkit: Enable external DP support") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250422-x1e001de-devkit-dts-fix-retimer-gpios-v2-1-0129c4f2b6d7@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e80100-qcp: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-6-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-5-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e80100-hp-omnibook-x14: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-4-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e80100-asus-vivobook-s15: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-3-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1e001de-devkit: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: 7b8a31e82b87 ("arm64: dts: qcom: Add X1E001DE Snapdragon Devkit for Windows") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-2-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: x1-crd: Fix vreg_l2j_1p2 voltageStephan Gerhold1-2/+2
In the ACPI DSDT table, PPP_RESOURCE_ID_LDO2_J is configured with 1256000 uV instead of the 1200000 uV we have currently in the device tree. Use the same for consistency and correctness. Cc: stable@vger.kernel.org Fixes: bd50b1f5b6f3 ("arm64: dts: qcom: x1e80100: Add Compute Reference Device") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250423-x1e-vreg-l2j-voltage-v1-1-24b6a2043025@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sc7280: add UFS operating pointsNeil Armstrong1-9/+43
Replace the deprecated freq-table-hz property with an operating points table with all supported frequencies and power levels. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250424-topic-sc7280-upstream-ufs-opps-v1-1-e63494d65f45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: qcs8300: Add cpufreq scaling nodeImran Shaik1-0/+30
Add cpufreq-hw node to support cpufreq scaling on QCS8300. Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250430-qcs8300-cpufreq-scaling-v2-1-ee41566b8c56@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sda660-ifc6560: Fix dt-validate warningAlexey Minnekhanov1-0/+2
If you remove clocks property, you should remove clock-names, too. Fixes warning with dtbs check: 'clocks' is a dependency of 'clock-names' Fixes: 34279d6e3f32c ("arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support") Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-4-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sdm660-lavender: Add missing USB phy supplyAlexey Minnekhanov1-0/+1
Fixes the following dtbs check error: phy@c012000: 'vdda-pll-supply' is a required property Fixes: e5d3e752b050e ("arm64: dts: qcom: sdm660-xiaomi-lavender: Add USB") Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-3-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: qcom: sdm630: Add modem metadata memAlexey Minnekhanov1-1/+7
Similarly to MSM8998, add and use modem metadata memory region. This does not seemingly affect device functionality. But it fixes DTBs check warning: remoteproc@4080000: memory-region: [[45], [46]] is too short Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250504115120.1432282-2-alexeymin@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06arm64: dts: ipq6018: drop standalone 'smem' nodeGabor Juhos1-6/+3
Since commit b5af64fceb04 ("soc: qcom: smem: Support reserved-memory description") the SMEM device can be instantiated directly from a reserved-memory node. The 'smem' node is defined in this way for each modern IPQ SoCs except for IPQ6018. In order to make it inline with the others, move the 'compatible' and the 'hwlock' properties into the respective reserved-memory node, and drop the standalone 'smem' node. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250506-ipq6018-drop-smem-v1-1-af99d177be2f@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-06Merge tag 'v6.15-rc5' into x86/msr, to pick up fixes and to resolve conflictsIngo Molnar14-26/+109
Conflicts: drivers/cpufreq/intel_pstate.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-05-06KVM: arm64: Propagate FGT masks to the nVHE hypervisorMarc Zyngier3-0/+22
The nVHE hypervisor needs to have access to its own view of the FGT masks, which unfortunately results in a bit of data duplication. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Unconditionally configure fine-grain trapsMark Rutland1-24/+15
... otherwise we can inherit the host configuration if this differs from the KVM configuration. Signed-off-by: Mark Rutland <mark.rutland@arm.com> [maz: simplified a couple of things] Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Use computed masks as sanitisers for FGT registersMarc Zyngier1-6/+6
Now that we have computed RES0 bits, use them to sanitise the guest view of FGT registers. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Add description of FGT bits leading to EC!=0x18Marc Zyngier1-6/+30
The current FTP tables are only concerned with the bits generating ESR_ELx.EC==0x18. However, we want an exhaustive view of what KVM really knows about. So let's add another small table that provides that extra information. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Compute FGT masks from KVM's own FGT tablesMarc Zyngier2-0/+120
In the process of decoupling KVM's view of the FGT bits from the wider architectural state, use KVM's own FGT tables to build a synthetic view of what is actually known. This allows for some checking along the way. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Plug FEAT_GCS handlingMarc Zyngier2-0/+19
We don't seem to be handling the GCS-specific exception class. Handle it by delivering an UNDEF to the guest, and populate the relevant trap bits. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Don't treat HCRX_EL2 as a FGT registerMarc Zyngier1-6/+3
Treating HCRX_EL2 as yet another FGT register seems excessive, and gets in a way of further improvements. It is actually simpler to just be explicit about the masking, so just to that. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Restrict ACCDATA_EL1 undef to FEAT_LS64_ACCDATA being disabledMarc Zyngier1-1/+3
We currently unconditionally make ACCDATA_EL1 accesses UNDEF. As we are about to support it, restrict the UNDEF behaviour to cases where FEAT_LS64_ACCDATA is not exposed to the guest. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Handle trapping of FEAT_LS64* instructionsMarc Zyngier1-0/+56
We generally don't expect FEAT_LS64* instructions to trap, unless they are trapped by a guest hypervisor. Otherwise, this is just the guest playing tricks on us by using an instruction that isn't advertised, which we handle with a well deserved UNDEF. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Simplify handling of negative FGT bitsMarc Zyngier1-37/+12
check_fgt_bit() and triage_sysreg_trap() implement the same thing twice for no good reason. We have to lookup the FGT register twice, as we don't communicate it. Similarly, we extract the register value at the wrong spot. Reorganise the code in a more logical way so that things are done at the correct location, removing a lot of duplication. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06KVM: arm64: Tighten handling of unknown FGT groupsMarc Zyngier1-2/+3
triage_sysreg_trap() assumes that it knows all the possible values for FGT groups, which won't be the case as we start adding more FGT registers (unless we add everything in one go, which is obviously undesirable). At the same time, it doesn't offer much in terms of debugging info when things go wrong. Turn the "__NR_FGT_GROUP_IDS__" case into a default, covering any unhandled value, and give the kernel hacker a bit of a clue about what's wrong (system register and full trap descriptor). Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Add FEAT_FGT2 capabilityMarc Zyngier2-0/+8
As we will eventually have to context-switch the FEAT_FGT2 registers in KVM (something that has been completely ignored so far), add a new cap that we will be able to check for. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Add syndrome information for trapped LD64B/ST64B{,V,V0}Marc Zyngier1-1/+7
Provide the architected EC and ISS values for all the FEAT_LS64* instructions. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: Remove duplicated sysreg encodingsMarc Zyngier1-11/+0
A bunch of sysregs are now generated from the sysreg file, so no need to carry separate definitions. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add system instructions trapped by HFGIRT2_EL2Marc Zyngier1-1/+4
Add the new CMOs trapped by HFGITR2_EL2. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add registers trapped by HDFG{R,W}TR2_EL2Marc Zyngier2-0/+353
Bulk addition of all the system registers trapped by HDFG{R,W}TR2_EL2. The descriptions are extracted from the BSD-licenced JSON file part of the 2025-03 drop from ARM. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add registers trapped by HFG{R,W}TR2_EL2Marc Zyngier1-0/+395
Bulk addition of all the system registers trapped by HFG{R,W}TR2_EL2. The descriptions are extracted from the BSD-licenced JSON file part of the 2025-03 drop from ARM. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update CPACR_EL1 descriptionMarc Zyngier1-1/+3
Add the couple of fields introduced with FEAT_NV2p1. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update TRBIDR_EL1 descriptionMarc Zyngier1-1/+6
Add the missing MPAM field. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update PMSIDR_EL1 descriptionMarc Zyngier1-2/+26
Add the missing SME, ALTCLK, FPF, EFT. CRR and FDS fields. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update ID_AA64PFR0_EL1 descriptionMarc Zyngier1-0/+1
Add the missing RASv2 description. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Replace HFGxTR_EL2 with HFG{R,W}TR_EL2Marc Zyngier9-193/+250
Treating HFGRTR_EL2 and HFGWTR_EL2 identically was a mistake. It makes things hard to reason about, has the potential to introduce bugs by giving a meaning to bits that are really reserved, and is in general a bad description of the architecture. Given that #defines are cheap, let's describe both registers as intended by the architecture, and repaint all the existing uses. Yes, this is painful. The registers themselves are generated from the JSON file in an automated way. Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add layout for HCR_EL2Marc Zyngier2-61/+132
Add HCR_EL2 to the sysreg file, more or less directly generated from the JSON file. Since the generated names significantly differ from the existing naming, express the old names in terms of the new one. One day, we'll fix this mess, but I'm not in any hurry. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Update ID_AA64MMFR4_EL1 descriptionMarc Zyngier1-3/+16
Resync the ID_AA64MMFR4_EL1 with the architectue description. This results in: - the new PoPS field - the new NV2P1 value for the NV_frac field - the new RMEGDI field - the new SRMASK field These fields have been generated from the reference JSON file. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06arm64: sysreg: Add ID_AA64ISAR1_EL1.LS64 encoding for FEAT_LS64WBMarc Zyngier1-0/+1
The 2024 extensions are adding yet another variant of LS64 (aptly named FEAT_LS64WB) supporting LS64 accesses to write-back memory, as well as 32 byte single-copy atomic accesses using pairs of FP registers. Add the relevant encoding to ID_AA64ISAR1_EL1.LS64. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-05-06x86/bhi: Do not set BHI_DIS_S in 32-bit modePawan Gupta2-5/+6
With the possibility of intra-mode BHI via cBPF, complete mitigation for BHI is to use IBHF (history fence) instruction with BHI_DIS_S set. Since this new instruction is only available in 64-bit mode, setting BHI_DIS_S in 32-bit mode is only a partial mitigation. Do not set BHI_DIS_S in 32-bit mode so as to avoid reporting misleading mitigated status. With this change IBHF won't be used in 32-bit mode, also remove the CONFIG_X86_64 check from emit_spectre_bhb_barrier(). Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
2025-05-06x86/bpf: Add IBHF call at end of classic BPFDaniel Sneddon2-3/+25
Classic BPF programs can be run by unprivileged users, allowing unprivileged code to execute inside the kernel. Attackers can use this to craft branch history in kernel mode that can influence the target of indirect branches. BHI_DIS_S provides user-kernel isolation of branch history, but cBPF can be used to bypass this protection by crafting branch history in kernel mode. To stop intra-mode attacks via cBPF programs, Intel created a new instruction Indirect Branch History Fence (IBHF). IBHF prevents the predicted targets of subsequent indirect branches from being influenced by branch history prior to the IBHF. IBHF is only effective while BHI_DIS_S is enabled. Add the IBHF instruction to cBPF jitted code's exit path. Add the new fence when the hardware mitigation is enabled (i.e., X86_FEATURE_CLEAR_BHB_HW is set) or after the software sequence (X86_FEATURE_CLEAR_BHB_LOOP) is being used in a virtual machine. Note that X86_FEATURE_CLEAR_BHB_HW and X86_FEATURE_CLEAR_BHB_LOOP are mutually exclusive, so the JIT compiler will only emit the new fence, not the SW sequence, when X86_FEATURE_CLEAR_BHB_HW is set. Hardware that enumerates BHI_NO basically has BHI_DIS_S protections always enabled, regardless of the value of BHI_DIS_S. Since BHI_DIS_S doesn't protect against intra-mode attacks, enumerate BHI bug on BHI_NO hardware as well. Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 17:00:01 +0300