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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6afdf188-a82e-4c46-a518-8d007cc85d23@arm.com>
Date: Thu, 8 Jan 2026 14:23:04 +0000
From: Suzuki K Poulose <suzuki.poulose@....com>
To: 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, aneesh.kumar@...nel.org, steven.price@....com,
 tabba@...gle.com
Subject: Re: [PATCH kvmtool v4 15/15] arm64: smccc: Start sending PSCI to
 userspace

On 08/01/2026 14:14, Marc Zyngier wrote:
> 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.
> 

Agreed, I will address this.

> 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.
> 

Cheers
Suzuki


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ