kernel/linux.git/include/linux/arm-smccc.h, branch v6.19.11

arm64: kvm, smccc: Fix vendor uuid

2025-07-21T17:18:51+00:00

Commit 13423063c7cb ("arm64: kvm, smccc: Introduce and use API for getting hypervisor UUID") replaced the explicit register constants with the UUID_INIT macro. However, there is an endian issue, meaning the UUID generated and used in the handshake didn't match UUID prior to the commit. The change in UUID causes the SMCCC vendor handshake to fail with older guest kernels, meaning devices such as PTP were not available in the guest. This patch updates the parameters to the macro to generate a UUID which matches the previous value, and re-establish backwards compatibility with older guest kernels. Fixes: 13423063c7cb ("arm64: kvm, smccc: Introduce and use API for getting hypervisor UUID") Signed-off-by: Jack Thomson Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/20250721130558.50823-1-jackabt.amazon@gmail.com Signed-off-by: Will Deacon

arm64: kvm, smccc: Introduce and use API for getting hypervisor UUID

2025-05-23T16:30:55+00:00

The KVM/arm64 uses SMCCC to detect hypervisor presence. That code is private, and it follows the SMCCC specification. Other existing and emerging hypervisor guest implementations can and should use that standard approach as well. Factor out a common infrastructure that the guests can use, update KVM to employ the new API. The central notion of the SMCCC method is the UUID of the hypervisor, and the new API follows that. No functional changes. Validated with a KVM/arm64 guest. Signed-off-by: Roman Kisel Acked-by: Arnd Bergmann Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20250428210742.435282-2-romank@linux.microsoft.com Signed-off-by: Wei Liu Message-ID: <20250428210742.435282-2-romank@linux.microsoft.com>

Merge tag 'soc-drivers-6.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

2025-03-27T16:05:55+00:00

Pull SoC driver updates from Arnd Bergmann: "These are the updates for SoC specific drivers and related subsystems: - Firmware driver updates for SCMI, FF-A and SMCCC firmware interfaces, adding support for additional firmware features including SoC identification and FF-A SRI callbacks as well as various bugfixes - Memory controller updates for Nvidia and Mediatek - Reset controller support for microchip sam9x7 and imx8qxp/imx8qm - New hardware support for multiple Mediatek, Renesas and Samsung Exynos chips - Minor updates on Zynq, Qualcomm, Amlogic, TI, Samsung, Nvidia and Apple chips There will be a follow up with a few more driver updates that are still causing build regressions at the moment" * tag 'soc-drivers-6.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (97 commits) irqchip: Add support for Amlogic A4 and A5 SoCs dt-bindings: interrupt-controller: Add support for Amlogic A4 and A5 SoCs reset: imx: fix incorrect module device table dt-bindings: power: qcom,kpss-acc-v2: add qcom,msm8916-acc compatible bus: qcom-ssc-block-bus: Fix the error handling path of qcom_ssc_block_bus_probe() bus: qcom-ssc-block-bus: Remove some duplicated iounmap() calls soc: qcom: pd-mapper: Add support for SDM630/636 reset: imx: Add SCU reset driver for i.MX8QXP and i.MX8QM dt-bindings: firmware: imx: add property reset-controller dt-bindings: reset: atmel,at91sam9260-reset: add sam9x7 memory: mtk-smi: Add ostd setting for mt8192 dt-bindings: soc: samsung: exynos-usi: Drop unnecessary status from example firmware: tegra: bpmp: Fix typo in bpmp-abi.h soc/tegra: pmc: Use str_enable_disable-like helpers soc: samsung: include linux/array_size.h where needed firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo() soc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200 soc: mediatek: mt8188-mmsys: Add support for DSC on VDO0 soc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro soc: mediatek: mt8365-mmsys: Fix routing table masks and values ...

firmware: smccc: Support optional Arm SMCCC SOC_ID name

2025-03-03T14:53:46+00:00

Issue Number 1.6 of the Arm SMC Calling Convention introduces an optional SOC_ID name string. If implemented, point the 'machine' field of the SoC Device Attributes at this string so that it will appear under /sys/bus/soc/devices/soc0/machine. On Arm SMC compliant SoCs, this will allow things like 'lscpu' to eventually get a SoC provider model name from there rather than each tool/utility needing to get a possibly inconsistent, obsolete, or incorrect model/machine name from its own hardcoded model/machine name table. Signed-off-by: Paul Benoit Cc: Mark Rutland Cc: Lorenzo Pieralisi Cc: Sudeep Holla Cc: linux-arm-kernel@lists.infradead.org Acked-by: Mark Rutland Message-Id: <20250219005932.3466-1-paul@os.amperecomputing.com> (sudeep.holla: Dropped regsize variable and used 8 instead as Mark suggested) Signed-off-by: Sudeep Holla

KVM: arm64: Specify hypercall ABI for retrieving target implementations

2025-02-26T21:30:18+00:00

If the Guest requires migration to multiple targets, these hypercalls will provide a way to retrieve the target CPU implementations from the user space VMM. Subsequent patch will use this to enable the associated errata. Suggested-by: Oliver Upton Suggested-by: Marc Zyngier Reviewed-by: Cornelia Huck Reviewed-by: Sebastian Ott Signed-off-by: Shameer Kolothum Link: https://lore.kernel.org/r/20250221140229.12588-3-shameerali.kolothum.thodi@huawei.com Signed-off-by: Oliver Upton

arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint

2024-11-07T11:18:52+00:00

SMCCCv1.3 added a hint bit which callers can set in an SMCCC function ID (AKA "FID") to indicate that it is acceptable for the SMCCC implementation to discard SVE and/or SME state over a specific SMCCC call. The kernel support for using this hint is broken and SMCCC calls may clobber the SVE and/or SME state of arbitrary tasks, though FPSIMD state is unaffected. The kernel support is intended to use the hint when there is no SVE or SME state to save, and to do this it checks whether TIF_FOREIGN_FPSTATE is set or TIF_SVE is clear in assembly code: | ldr , [, #TSK_TI_FLAGS] | tbnz , #TIF_FOREIGN_FPSTATE, 1f // Any live FP state? | tbnz , #TIF_SVE, 2f // Does that state include SVE? | | 1: orr , , ARM_SMCCC_1_3_SVE_HINT | 2: | << SMCCC call using FID >> This is not safe as-is: (1) SMCCC calls can be made in a preemptible context and preemption can result in TIF_FOREIGN_FPSTATE being set or cleared at arbitrary points in time. Thus checking for TIF_FOREIGN_FPSTATE provides no guarantee. (2) TIF_FOREIGN_FPSTATE only indicates that the live FP/SVE/SME state in the CPU does not belong to the current task, and does not indicate that clobbering this state is acceptable. When the live CPU state is clobbered it is necessary to update fpsimd_last_state.st to ensure that a subsequent context switch will reload FP/SVE/SME state from memory rather than consuming the clobbered state. This and the SMCCC call itself must happen in a critical section with preemption disabled to avoid races. (3) Live SVE/SME state can exist with TIF_SVE clear (e.g. with only TIF_SME set), and checking TIF_SVE alone is insufficient. Remove the broken support for the SMCCCv1.3 SVE saving hint. This is effectively a revert of commits: * cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint") * a7c3acca5380 ("arm64: smccc: Save lr before calling __arm_smccc_sve_check()") ... leaving behind the ARM_SMCCC_VERSION_1_3 and ARM_SMCCC_1_3_SVE_HINT definitions, since these are simply definitions from the SMCCC specification, and the latter is used in KVM via ARM_SMCCC_CALL_HINTS. If we want to bring this back in future, we'll probably want to handle this logic in C where we can use all the usual FPSIMD/SVE/SME helper functions, and that'll likely require some rework of the SMCCC code and/or its callers. Fixes: cfa7ff959a78 ("arm64: smccc: Support SMCCC v1.3 SVE register saving hint") Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Cc: stable@vger.kernel.org Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20241106160448.2712997-1-mark.rutland@arm.com Signed-off-by: Will Deacon

arm64: smccc: Reserve block of KVM "vendor" services for pKVM hypercalls

2024-08-30T15:30:41+00:00

pKVM relies on hypercalls to expose services such as memory sharing to protected guests. Tentatively allocate a block of 58 hypercalls (i.e. fill the remaining space in the first 64 function IDs) for pKVM usage, as future extensions such as pvIOMMU support, range-based memory sharing and validation of assigned devices will require additional services. Suggested-by: Marc Zyngier Link: https://lore.kernel.org/r/86a5h5yg5y.wl-maz@kernel.org Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20240830130150.8568-8-will@kernel.org Signed-off-by: Will Deacon

drivers/virt: pkvm: Intercept ioremap using pKVM MMIO_GUARD hypercall

2024-08-30T15:30:41+00:00

Hook up pKVM's MMIO_GUARD hypercall so that ioremap() and friends will register the target physical address as MMIO with the hypervisor, allowing guest exits to that page to be emulated by the host with full syndrome information. Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20240830130150.8568-7-will@kernel.org Signed-off-by: Will Deacon

drivers/virt: pkvm: Hook up mem_encrypt API using pKVM hypercalls

2024-08-30T15:30:41+00:00

If we detect the presence of pKVM's SHARE and UNSHARE hypercalls, then register a backend implementation of the mem_encrypt API so that things like DMA buffers can be shared appropriately with the host. Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20240830130150.8568-5-will@kernel.org Signed-off-by: Will Deacon

drivers/virt: pkvm: Add initial support for running as a protected guest

2024-08-30T15:30:41+00:00

Implement a pKVM protected guest driver to probe the presence of pKVM and determine the memory protection granule using the HYP_MEMINFO hypercall. Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20240830130150.8568-3-will@kernel.org Signed-off-by: Will Deacon