[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86jz418rh3.wl-maz@kernel.org>
Date: Mon, 21 Jul 2025 16:59:36 +0100
From: Marc Zyngier <maz@...nel.org>
To: Jack Thomson <jackabt.amazon@...il.com>,
Will Deacon <will@...nel.org>
Cc: mark.rutland@....com,
lpieralisi@...nel.org,
sudeep.holla@....com,
arnd@...db.de,
wei.liu@...nel.org,
romank@...ux.microsoft.com,
mhklinux@...look.com,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
oliver.upton@...ux.dev,
kvmarm@...ts.linux.dev,
roypat@...zon.com,
Jack Thomson <jackabt@...zon.com>
Subject: Re: [PATCH] arm64: kvm, smccc: Fix vendor uuid
[+Will]
On Mon, 21 Jul 2025 14:05:58 +0100,
Jack Thomson <jackabt.amazon@...il.com> wrote:
>
> From: Jack Thomson <jackabt@...zon.com>
>
> Commit 13423063c7cb ("arm64: kvm, smccc: Introduce and use API for
> getting hypervisor UUID") replaced the explicit register constants
> with the UUID_INIT macro. However, there is an endian issue, meaning
> the UUID generated and used in the handshake didn't match UUID prior to
> the commit.
>
> The change in UUID causes the SMCCC vendor handshake to fail with older
> guest kernels, meaning devices such as PTP were not available in the
> guest.
>
> This patch updates the parameters to the macro to generate a UUID which
> matches the previous value, and re-establish backwards compatibility
> with older guest kernels.
>
> Fixes: 13423063c7cb ("arm64: kvm, smccc: Introduce and use API for getting hypervisor UUID")
> getting hypervisor UUID")
> Signed-off-by: Jack Thomson <jackabt@...zon.com>
> ---
> include/linux/arm-smccc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 784ebe4607a4..50b47eba7d01 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -113,7 +113,7 @@
>
> /* KVM UID value: 28b46fb6-2ec5-11e9-a9ca-4b564d003a74 */
> #define ARM_SMCCC_VENDOR_HYP_UID_KVM UUID_INIT(\
> - 0xb66fb428, 0xc52e, 0xe911, \
> + 0x28b46fb6, 0x2ec5, 0x11e9, \
> 0xa9, 0xca, 0x4b, 0x56, \
> 0x4d, 0x00, 0x3a, 0x74)
>
>
Irk. This is remarkably embarrassing, and needs to be addressed ASAP,
before 6.16 ships. FWIW, I've just posted a quickly whipped selftest
that shows the problem[1].
Will, is there a chance you can pick this up and ferry it to Linus?
If you do, please add:
Reviewed-by: Marc Zyngier <maz@...nel.org>
Tested-by: Marc Zyngier <maz@...nel.org>
Thanks,
M.
[1] https://lore.kernel.org/r/20250721155136.892255-1-maz@kernel.org
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists