From: Roman Kisel <romank@linux.microsoft.com>
To: "Arnd Bergmann" <arnd@arndb.de>,
bhelgaas@google.com, "Borislav Petkov" <bp@alien8.de>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Conor Dooley" <conor+dt@kernel.org>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"Dexuan Cui" <decui@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"H. Peter Anvin" <hpa@zytor.com>,
krzk+dt@kernel.org, "Krzysztof Wilczyński" <kw@linux.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
"Ingo Molnar" <mingo@redhat.com>, "Rob Herring" <robh@kernel.org>,
ssengar@linux.microsoft.com,
"Thomas Gleixner" <tglx@linutronix.de>,
"Wei Liu" <wei.liu@kernel.org>, "Will Deacon" <will@kernel.org>,
devicetree@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, x86@kernel.org
Cc: benhill@microsoft.com, bperkins@microsoft.com, sunilmut@microsoft.com
Subject: Re: [PATCH hyperv-next v4 1/6] arm64: hyperv: Use SMCCC to detect hypervisor presence
Date: Fri, 14 Feb 2025 08:47:32 -0800 [thread overview]
Message-ID: <6e4685fe-68e9-43bd-96c5-b871edb1b971@linux.microsoft.com> (raw)
In-Reply-To: <97887849-faa8-429b-862b-daf6faf89481@app.fastmail.com>
On 2/14/2025 12:05 AM, Arnd Bergmann wrote:
> On Fri, Feb 14, 2025, at 00:23, Roman Kisel wrote:
>> On 2/11/2025 10:54 PM, Arnd Bergmann wrote:
>
>> index a74600d9f2d7..86f75f44895f 100644
>> --- a/drivers/firmware/smccc/smccc.c
>> +++ b/drivers/firmware/smccc/smccc.c
>> @@ -67,6 +67,30 @@ s32 arm_smccc_get_soc_id_revision(void)
>> }
>> EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
>>
>> +bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
>
> The interface looks good to me.
Great :)
>
>> +{
>> + struct arm_smccc_res res = {};
>> + struct {
>> + u32 dwords[4]
>> + } __packed res_uuid;
>
> The structure definition here looks odd because of the
> unexplained __packed attribute and the nonstandard byteorder.
>
Fair points, thank you, will straighten this out!
> The normal uuid_t is defined as an array of 16 bytes,
> so if you try to represent it in 32-bit words you need to
> decide between __le32 and __be32 representation.
>
>> + 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);
>> + if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
>> + return false;
>> +
>> + res_uuid.dwords[0] = res.a0;
>> + res_uuid.dwords[1] = res.a1;
>> + res_uuid.dwords[2] = res.a2;
>> + res_uuid.dwords[3] = res.a3;
>> +
>> + return uuid_equal((uuid_t *)&res_uuid, hyp_uuid);
>
> The SMCCC standard defines the four words to be little-endian,
> so in order to compare them against a uuid byte array, you'd
> need to declare the array as __le32 and swap the result
> members with cpu_to_le32().
>
> Alternatively you could pass the four u32 values into the
> function in place of the uuid.
>
> Since the callers have the same endianess confusion, your
> implementation ends up working correctly even on big-endian,
> but I find it harder to follow when you call uuid_equal() on
> something that is not the actual uuid_t value.
>
I'll make sure the implementation is clearer, thanks!
>> +
>> +#define ARM_SMCCC_HYP_PRESENT(HYP) \
>> + ({ \
>> + const u32 uuid_as_dwords[4] = { \
>> + ARM_SMCCC_VENDOR_HYP_UID_ ## HYP ## _REG_0, \
>> + ARM_SMCCC_VENDOR_HYP_UID_ ## HYP ## _REG_1, \
>
> I don't think using a macro is helpful here, it just makes
> it impossible to grep for ARM_SMCCC_VENDOR_HYP_UID_* values when
> reading the source.
>
> I would suggest moving the UUID values into a variable next
> to the caller like
>
> #define ARM_SMCCC_VENDOR_HYP_UID_KVM \
> UUID_INIT(0x28b46fb6, 0x2ec5, 0x11e9, 0xa9, 0xca, 0x4b, 0x56, 0x4d, 0x00, 0x3a, 0x74)
>
> and then just pass that into arm_smccc_hyp_present(). (please
> double-check the endianess of the definition here, I probably
> got it wrong myself).
Will remove the macro and will use UUID_INIT, appreciate taking the
time to review the draft and your suggestions on improving it very much!
>
> Arnd
--
Thank you,
Roman
next prev parent reply other threads:[~2025-02-14 16:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 1:43 [PATCH hyperv-next v4 0/6] arm64: hyperv: Support Virtual Trust Level Boot Roman Kisel
2025-02-12 1:43 ` [PATCH hyperv-next v4 1/6] arm64: hyperv: Use SMCCC to detect hypervisor presence Roman Kisel
2025-02-12 6:54 ` Arnd Bergmann
2025-02-13 23:23 ` Roman Kisel
2025-02-14 8:05 ` Arnd Bergmann
2025-02-14 16:47 ` Roman Kisel [this message]
2025-02-24 23:22 ` Roman Kisel
2025-02-25 7:24 ` Arnd Bergmann
2025-02-25 22:25 ` Roman Kisel
2025-02-26 13:57 ` Arnd Bergmann
2025-02-19 23:13 ` Michael Kelley
2025-02-20 16:34 ` Roman Kisel
2025-02-12 1:43 ` [PATCH hyperv-next v4 2/6] Drivers: hv: Enable VTL mode for arm64 Roman Kisel
2025-02-19 23:14 ` Michael Kelley
2025-02-20 16:36 ` Roman Kisel
2025-02-12 1:43 ` [PATCH hyperv-next v4 3/6] Drivers: hv: Provide arch-neutral implementation of get_vtl() Roman Kisel
2025-02-19 23:17 ` Michael Kelley
2025-02-12 1:43 ` [PATCH hyperv-next v4 4/6] dt-bindings: microsoft,vmbus: Add GIC and DMA coherence to the example Roman Kisel
2025-02-12 6:42 ` Krzysztof Kozlowski
2025-02-12 23:57 ` Roman Kisel
2025-02-13 20:50 ` Roman Kisel
2025-02-12 1:43 ` [PATCH hyperv-next v4 5/6] Drivers: hv: vmbus: Get the IRQ number from DeviceTree Roman Kisel
2025-02-19 23:20 ` Michael Kelley
2025-02-12 1:43 ` [PATCH hyperv-next v4 6/6] PCI: hv: Get vPCI MSI IRQ domain " Roman Kisel
2025-02-12 17:42 ` Bjorn Helgaas
2025-02-18 22:32 ` Roman Kisel
2025-02-19 23:51 ` Roman Kisel
2025-02-19 23:29 ` Michael Kelley
2025-02-20 16:41 ` Roman Kisel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6e4685fe-68e9-43bd-96c5-b871edb1b971@linux.microsoft.com \
--to=romank@linux.microsoft.com \
--cc=arnd@arndb.de \
--cc=benhill@microsoft.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=bperkins@microsoft.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=devicetree@vger.kernel.org \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=krzk+dt@kernel.org \
--cc=kw@linux.com \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=mingo@redhat.com \
--cc=robh@kernel.org \
--cc=ssengar@linux.microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.