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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 09/01/2026 10:43, Aneesh Kumar K.V wrote:
> 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[]?.

Yep, that can done in respective patches, where we add RHI. Since we
only have psci in the ranges, I am a bit lazy/reluctant to rename it.

Cheers
Suzuki

> 
> -aneesh