linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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



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