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:56 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).