diff options
| author | Oliver Upton <oliver.upton@linux.dev> | 2023-04-04 15:40:42 +0000 |
|---|---|---|
| committer | Marc Zyngier <maz@kernel.org> | 2023-04-05 12:07:41 +0100 |
| commit | c2d2e9b3d8ce9db825a5630d9d52d542f5138ae0 (patch) | |
| tree | 6a3cd7514f4587c1235851f6e5c2329867649703 /arch/arm64/include | |
| parent | aac94968126beb9846c12a940f1302ece7849b4f (diff) | |
| download | linux-stable-c2d2e9b3d8ce9db825a5630d9d52d542f5138ae0.tar.gz linux-stable-c2d2e9b3d8ce9db825a5630d9d52d542f5138ae0.tar.bz2 linux-stable-c2d2e9b3d8ce9db825a5630d9d52d542f5138ae0.zip | |
KVM: arm64: Start handling SMCs from EL1
Whelp, the architecture gods have spoken and confirmed that the function
ID space is common between SMCs and HVCs. Not only that, the expectation
is that hypervisors handle calls to both SMC and HVC conduits. KVM
recently picked up support for SMCCCs in commit bd36b1a9eb5a ("KVM:
arm64: nv: Handle SMCs taken from virtual EL2") but scoped it only to a
nested hypervisor.
Let's just open the floodgates and let EL1 access our SMCCC
implementation with the SMC instruction as well.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230404154050.2270077-6-oliver.upton@linux.dev
Diffstat (limited to 'arch/arm64/include')
0 files changed, 0 insertions, 0 deletions