From: Roman Kisel <romank@linux.microsoft.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: arnd@arndb.de, bhelgaas@google.com, bp@alien8.de,
catalin.marinas@arm.com, conor+dt@kernel.org,
dan.carpenter@linaro.org, dave.hansen@linux.intel.com,
decui@microsoft.com, haiyangz@microsoft.com, hpa@zytor.com,
joey.gouly@arm.com, krzk+dt@kernel.org, kw@linux.com,
kys@microsoft.com, lenb@kernel.org, lpieralisi@kernel.org,
manivannan.sadhasivam@linaro.org, maz@kernel.org,
mingo@redhat.com, oliver.upton@linux.dev, rafael@kernel.org,
robh@kernel.org, ssengar@linux.microsoft.com,
sudeep.holla@arm.com, suzuki.poulose@arm.com, tglx@linutronix.de,
wei.liu@kernel.org, will@kernel.org, yuzenghui@huawei.com,
devicetree@vger.kernel.org, kvmarm@lists.linux.dev,
linux-acpi@vger.kernel.org, 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, apais@microsoft.com,
benhill@microsoft.com, bperkins@microsoft.com,
sunilmut@microsoft.com
Subject: Re: [PATCH hyperv-next v6 01/11] arm64: kvm, smccc: Introduce and use API for detecting hypervisor presence
Date: Mon, 17 Mar 2025 10:11:32 -0700 [thread overview]
Message-ID: <d168a483-b425-4c18-ad71-eb39a0aba06c@linux.microsoft.com> (raw)
In-Reply-To: <Z9gHmkNOsd29viHj@J2N7QTR9R3.cambridge.arm.com>
On 3/17/2025 4:29 AM, Mark Rutland wrote:
> On Fri, Mar 14, 2025 at 05:19:21PM -0700, Roman Kisel wrote:
[...]
>> +}
>
> This use of a statement expression is bizarre, and the function would be
> clearer without it, e.g.
I'll change that to what you're suggesting, thanks for your help!
>
> | bool arm_smccc_hyp_present(const uuid_t *hyp_uuid)
> | {
> | struct arm_smccc_res res = {};
> | uuid_t uuid;
> |
> | 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;
> |
> | uuid_t = SMCCC_RES_TO_UUID(res.a0, res.a1, res.a2, res.a3);
> | return uuid_equal(&uuid, hyp_uuid);
> | }
>
> As noted below, I'd prefer if this were renamed to something like
> arm_smccc_hypervisor_has_uuid(), to more clearly indicate what is being
> checked.
>
> [...]
Will update, thanks for your help!
>
>> +/**
>> + * arm_smccc_hyp_present(const uuid_t *hyp_uuid)
>> + *
>> + * Returns `true` if the hypervisor advertises its presence via SMCCC.
>> + *
>> + * When the function returns `false`, the caller shall not assume that
>> + * there is no hypervisor running. Instead, the caller must fall back to
>> + * other approaches if any are available.
>> + */
>> +bool arm_smccc_hyp_present(const uuid_t *hyp_uuid);
>
> I'd prefer if this were:
>
> | /*
> | * Returns whether a specific hypervisor UUID is advertised for the
> | * Vendor Specific Hypervisor Service range.
> | */
> | bool arm_smccc_hypervisor_has_uuid(const uuid_t *uuid);
>
[...]
>
> I think this'd be clearer if we did something similar to what we did for
> the SMCCC SOC_ID name:
>
> https://lore.kernel.org/linux-arm-kernel/20250219005932.3466-1-paul@os.amperecomputing.com/
>
> ... and pack/unpack the bytes explicitly, e.g.
That looks great, thanks for the suggestion!
>
> | static inline uuid smccc_res_to_uuid(u32 r0, u32, r1, u32 r2, u32 r3)
> | {
> | uuid_t uuid = {
> | .b = {
> | [0] = (r0 >> 0) & 0xff,
> | [1] = (r0 >> 8) & 0xff,
> | [2] = (r0 >> 16) & 0xff,
> | [3] = (r0 >> 24) & 0xff,
> |
> | [4] = (r1 >> 0) & 0xff,
> | [5] = (r1 >> 8) & 0xff,
> | [6] = (r1 >> 16) & 0xff,
> | [7] = (r1 >> 24) & 0xff,
> |
> | [8] = (r2 >> 0) & 0xff,
> | [9] = (r2 >> 8) & 0xff,
> | [10] = (r2 >> 16) & 0xff,
> | [11] = (r2 >> 24) & 0xff,
> |
> | [12] = (r3 >> 0) & 0xff,
> | [13] = (r3 >> 8) & 0xff,
> | [14] = (r3 >> 16) & 0xff,
> | [15] = (r3 >> 24) & 0xff,
> | },
> | };
> |
> | return uuid;
> | }
>
> ... which is a bit more verbose, but clearly aligns with what the SMCCC
> spec says w.r.t. packing/unpacking, and should avoid warnings about
> endianness conversions.
>
I believe what you're proposing hits a better trade-off, thanks again!
>> +
>> +#define UUID_TO_SMCCC_RES(uuid_init, regs) do { \
>> + const uuid_t uuid = uuid_init; \
>> + (regs)[0] = le32_to_cpu((u32)uuid.b[0] | (uuid.b[1] << 8) | \
>> + ((uuid.b[2]) << 16) | ((uuid.b[3]) << 24)); \
>> + (regs)[1] = le32_to_cpu((u32)uuid.b[4] | (uuid.b[5] << 8) | \
>> + ((uuid.b[6]) << 16) | ((uuid.b[7]) << 24)); \
>> + (regs)[2] = le32_to_cpu((u32)uuid.b[8] | (uuid.b[9] << 8) | \
>> + ((uuid.b[10]) << 16) | ((uuid.b[11]) << 24)); \
>> + (regs)[3] = le32_to_cpu((u32)uuid.b[12] | (uuid.b[13] << 8) | \
>> + ((uuid.b[14]) << 16) | ((uuid.b[15]) << 24)); \
>> + } while (0)
>> +
>> +#endif /* !__ASSEMBLER__ */
>
> IMO it'd be clearer to initialise a uuid_t beforehand, and then allow
> the helper to unpack the bytes, e.g.
>
> static inline u32 smccc_uuid_to_reg(const uuid_t uuid, int reg)
> {
> u32 val = 0;
>
> val |= (u32)(uuid.b[4 * reg + 0] << 0)
> val |= (u32)(uuid.b[4 * reg + 1] << 8)
> val |= (u32)(uuid.b[4 * reg + 2] << 16)
> val |= (u32)(uuid.b[4 * reg + 3] << 24)
>
> return val:
> }
>
> #define UUID_TO_SMCCC_RES(uuid, regs) \
> do { \
> (regs)[0] = smccc_uuid_to_reg(uuid, 0); \
> (regs)[1] = smccc_uuid_to_reg(uuid, 1); \
> (regs)[2] = smccc_uuid_to_reg(uuid, 2); \
> (regs)[3] = smccc_uuid_to_reg(uuid, 3); \
> } while (0)
>
> ... though arguably at that point you can get rid of the
> UUID_TO_SMCCC_RES() macro and just expand that directly at the callsite.
>
I'll work on that, thanks!!
> Mark.
--
Thank you,
Roman
next prev parent reply other threads:[~2025-03-17 17:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 0:19 [PATCH hyperv-next v6 00/11] arm64: hyperv: Support Virtual Trust Level Boot Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 01/11] arm64: kvm, smccc: Introduce and use API for detecting hypervisor presence Roman Kisel
2025-03-15 0:27 ` Roman Kisel
2025-03-15 13:12 ` Arnd Bergmann
2025-03-17 17:28 ` Roman Kisel
2025-03-17 11:29 ` Mark Rutland
2025-03-17 17:11 ` Roman Kisel [this message]
2025-03-15 0:19 ` [PATCH hyperv-next v6 02/11] arm64: hyperv: Use SMCCC to detect " Roman Kisel
2025-03-17 11:37 ` Mark Rutland
2025-03-17 17:12 ` Roman Kisel
2025-03-19 22:11 ` Michael Kelley
2025-03-20 18:47 ` Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 03/11] Drivers: hv: Enable VTL mode for arm64 Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 04/11] Drivers: hv: Provide arch-neutral implementation of get_vtl() Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 05/11] arm64: hyperv: Initialize the Virtual Trust Level field Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 06/11] arm64, x86: hyperv: Report the VTL the system boots in Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 07/11] dt-bindings: microsoft,vmbus: Add interrupt and DMA coherence properties Roman Kisel
2025-03-16 17:36 ` Krzysztof Kozlowski
2025-03-17 17:07 ` Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 08/11] Drivers: hv: vmbus: Get the IRQ number from DeviceTree Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 09/11] Drivers: hv: vmbus: Introduce hv_get_vmbus_root_device() Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 10/11] ACPI: irq: Introduce acpi_get_gsi_dispatcher() Roman Kisel
2025-03-26 14:55 ` Rafael J. Wysocki
2025-03-26 15:32 ` Roman Kisel
2025-03-15 0:19 ` [PATCH hyperv-next v6 11/11] PCI: hv: Get vPCI MSI IRQ domain from DeviceTree Roman Kisel
2025-03-15 18:49 ` Bjorn Helgaas
2025-03-17 17:07 ` Roman Kisel
2025-03-26 14:56 ` Rafael J. Wysocki
2025-03-26 15:37 ` 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=d168a483-b425-4c18-ad71-eb39a0aba06c@linux.microsoft.com \
--to=romank@linux.microsoft.com \
--cc=apais@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=dan.carpenter@linaro.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=joey.gouly@arm.com \
--cc=krzk+dt@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=kw@linux.com \
--cc=kys@microsoft.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--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=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=oliver.upton@linux.dev \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=ssengar@linux.microsoft.com \
--cc=sudeep.holla@arm.com \
--cc=sunilmut@microsoft.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yuzenghui@huawei.com \
/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