lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq5aa4yn5x6e.fsf@kernel.org>
Date: Fri, 09 Jan 2026 08:06:57 +0530
From: Aneesh Kumar K.V <aneesh.kumar@...nel.org>
To: Marc Zyngier <maz@...nel.org>,
	Suzuki K Poulose <suzuki.poulose@....com>
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

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?

-aneesh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ