[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e0689753-2d17-4593-a7f6-b8211cc29e8d@arm.com>
Date: Fri, 9 Jan 2026 10:21:01 +0000
From: Suzuki K Poulose <suzuki.poulose@....com>
To: "Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
Marc Zyngier <maz@...nel.org>
Cc: kvmarm@...ts.linux.dev, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, will@...nel.org, oliver.upton@...ux.dev,
alexandru.elisei@....com, steven.price@....com, tabba@...gle.com
Subject: Re: [PATCH kvmtool v4 15/15] arm64: smccc: Start sending PSCI to
userspace
On 09/01/2026 02:36, Aneesh Kumar K.V wrote:
> Marc Zyngier <maz@...nel.org> writes:
>
>> On Tue, 30 Sep 2025 11:31:30 +0100,
>> Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>>
>>> From: Oliver Upton <oliver.upton@...ux.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@...ux.dev>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....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.
Suzuki
>
> -aneesh
Powered by blists - more mailing lists