RE: [PATCH v3 1/7] arm64: hyperv: Use SMC to detect hypervisor presence
From: Michael Kelley <hidden>
Date: 2024-08-05 03:01:43
Also in:
linux-acpi, linux-arch, linux-hyperv, linux-pci, lkml
From: Roman Kisel <redacted> Sent: Friday, July 26, 2024 3:59 PM
The arm64 Hyper-V startup path relies on ACPI to detect running under a Hyper-V compatible hypervisor. That doesn't work on non-ACPI systems. Hoist the ACPI detection logic into a separate function, use the new SMC added recently to Hyper-V to use in the non-ACPI case.
Wording seems slightly messed up. Perhaps: Hoist the ACPI detection logic into a separate function. Then use the new SMC added recently to Hyper-V in the non-ACPI case. Also, the phrase "the new SMC" seems a bit off to me. The "Terms and Abbreviations" section of the SMCCC specification defines "SMC" as an instruction: Secure Monitor Call. An Arm assembler instruction that causes an exception that is taken synchronously into EL3. More precisely, I think you mean a SMC "function identifier" that is newly implemented by Hyper-V. And the function identifier itself isn't new; it's the Hyper-V implementation that's new. Similar comment applies in the cover letter for this patch set, and perhaps to the Subject line of this patch.
quoted hunk ↗ jump to hunk
Signed-off-by: Roman Kisel <redacted> --- arch/arm64/hyperv/mshyperv.c | 36 ++++++++++++++++++++++++++----- arch/arm64/include/asm/mshyperv.h | 5 +++++ 2 files changed, 36 insertions(+), 5 deletions(-)diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c index b1a4de4eee29..341f98312667 100644 --- a/arch/arm64/hyperv/mshyperv.c +++ b/arch/arm64/hyperv/mshyperv.c@@ -27,6 +27,34 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info) return 0; } +static bool hyperv_detect_via_acpi(void) +{ + if (acpi_disabled) + return false; +#if IS_ENABLED(CONFIG_ACPI) + /* Hypervisor ID is only available in ACPI v6+. */ + if (acpi_gbl_FADT.header.revision < 6) + return false; + return strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8) == 0; +#else + return false; +#endif +} + +static bool hyperv_detect_via_smc(void) +{ + struct arm_smccc_res res = {}; + + if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_HVC) + return false; + arm_smccc_1_1_hvc(ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID, &res); + + return res.a0 == ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_0 && + res.a1 == ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_1 && + res.a2 == ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_2 && + res.a3 == ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_3; +} + static int __init hyperv_init(void) { struct hv_get_vp_registers_output result;@@ -35,13 +63,11 @@ static int __init hyperv_init(void) /* * Allow for a kernel built with CONFIG_HYPERV to be running in - * a non-Hyper-V environment, including on DT instead of ACPI. + * a non-Hyper-V environment. + * * In such cases, do nothing and return success. */ - if (acpi_disabled) - return 0; - - if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8)) + if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smc()) return 0; /* Setup the guest ID */diff --git a/arch/arm64/include/asm/mshyperv.hb/arch/arm64/include/asm/mshyperv.h index a975e1a689dd..a7a3586f7cb1 100644--- a/arch/arm64/include/asm/mshyperv.h +++ b/arch/arm64/include/asm/mshyperv.h@@ -51,4 +51,9 @@ static inline u64 hv_get_msr(unsigned int reg) #include <asm-generic/mshyperv.h> +#define ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_0 0x7948734d +#define ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_1 0x56726570 +#define ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_2 0 +#define ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_3 0 +
Section 6.2 of the SMCCC specification says that the "Call UID Query" returns a UUID. The above #defines look like an ASCII string is being returned. Arguably the ASCII string can be treated as a set of 128 bits just like a UUID, but it doesn't meet the spirit of the spec. Can Hyper-V be changed to return a real UUID? While the distinction probably won't make a material difference here, we've had problems in the past with Hyper-V doing slightly weird things that later caused unexpected trouble. Please just get it right. :-) Michael
#endif -- 2.34.1