Re: [PATCH kvmtool v4 15/15] arm64: smccc: Start sending PSCI to userspace

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Suzuki K Poulose <suzuki.poulose@arm.com> writes:

> On 09/01/2026 02:36, Aneesh Kumar K.V wrote:
>> Marc Zyngier <maz@kernel.org> writes:
>> 
>>> On Tue, 30 Sep 2025 11:31:30 +0100,
>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>
>>>> From: Oliver Upton <oliver.upton@linux.dev>
>>>>
>>>> kvmtool now has a PSCI implementation that complies with v1.0 of the
>>>> specification. Use the SMCCC filter to start sending these calls out to
>>>> userspace for further handling. While at it, shut the door on the
>>>> legacy, KVM-specific v0.1 functions.
>>>>
>>>> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> ---
>>>>   arm64/include/kvm/kvm-config-arch.h |  8 +++++--
>>>>   arm64/smccc.c                       | 37 +++++++++++++++++++++++++++++
>>>>   2 files changed, 43 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arm64/include/kvm/kvm-config-arch.h b/arm64/include/kvm/kvm-config-arch.h
>>>> index ee031f01..3158fadf 100644
>>>> --- a/arm64/include/kvm/kvm-config-arch.h
>>>> +++ b/arm64/include/kvm/kvm-config-arch.h
>>>> @@ -15,6 +15,7 @@ struct kvm_config_arch {
>>>>   	u64		fw_addr;
>>>>   	unsigned int	sve_max_vq;
>>>>   	bool		no_pvtime;
>>>> +	bool		in_kernel_smccc;
>>>>   };
>>>>   
>>>>   int irqchip_parser(const struct option *opt, const char *arg, int unset);
>>>> @@ -52,11 +53,14 @@ int sve_vl_parser(const struct option *opt, const char *arg, int unset);
>>>>   			   "Force virtio devices to use PCI as their default "	\
>>>>   			   "transport (Deprecated: Use --virtio-transport "	\
>>>>   			   "option instead)", virtio_transport_parser, kvm),	\
>>>> -        OPT_CALLBACK('\0', "irqchip", &(cfg)->irqchip,				\
>>>> +	OPT_CALLBACK('\0', "irqchip", &(cfg)->irqchip,				\
>>>>   		     "[gicv2|gicv2m|gicv3|gicv3-its]",				\
>>>>   		     "Type of interrupt controller to emulate in the guest",	\
>>>>   		     irqchip_parser, NULL),					\
>>>>   	OPT_U64('\0', "firmware-address", &(cfg)->fw_addr,			\
>>>> -		"Address where firmware should be loaded"),
>>>> +		"Address where firmware should be loaded"),			\
>>>> +	OPT_BOOLEAN('\0', "in-kernel-smccc", &(cfg)->in_kernel_smccc,		\
>>>> +			"Disable userspace handling of SMCCC, instead"		\
>>>> +			" relying on the in-kernel implementation"),
>>>>
>>>
>>> nit: this really is about PSCI, not SMCCC. The fact that we use the
>>> SMCCC interface to route PSCI calls is an implementation detail,
>>> really. The other thing is that this is a change in default behaviour,
>>> and I'd rather keep in-kernel PSCI to be the default, specially given
>>> that this otherwise silently fails on old kernels.
>>>
>>> To that effect, I'd suggest the following instead:
>>>
>>> +	OPT_BOOLEAN('\0', "psci", &(cfg)->userspace_psci,		\
>>> +			"Request userspace handling of PSCI, instead"		\
>>> +			" relying on the in-kernel implementation"),
>>>
>>> and the code modified accordingly.
>>>
>> 
>> The same option will also be used to handle RHI or may be we could say
>> --realm implies userspace_psci = true?
>
> Not necessarily. For a Realm, we should always handle the RHI calls in
> VMM and VMM must do this irrespective of where the PSCI is emulated.
> i.e., they both are different things. KVM allows controlling the SMCCC
> for FID ranges. For Realm, RHI range can be requested by the VMM.
> Depending on the --psci option, PSCI range can also be requested.
>

We can rename static struct kvm_smccc_filter filter_ranges[] to
psci_filter_ranges[] and for RHI we can have another
rhi_smccc_fid_ranges[]?.

-aneesh