From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 251E1C021B2 for ; Tue, 25 Feb 2025 22:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4snbY5kKjPs+fqnW4bDVzUWCVcYb+NMujdrOx1UsTIo=; b=Mo1GcJHFFOp+zYLql16pGu3+ob j/UG4MSlZQaTWp2rIgVL+f6PrYj3Wa24XrqN6Mh/c4d0yXniI6Oh4FhcPM/1PLIwe27HGe8kPLHra wYiogUhVdPsGzDbR78sHiMkMTFlE4bVfJwz0trz389hMNCOUy7do5pqXTrfsdtA8dyZsqF/eeRZXK cFikHGIcpP291bzs5rG6xWex0j34/zfCRMbQchxVhV8VuisOxaVu1dtqcXNAub2T6wzjmjJNN5DbF PLaVCQd5T4bTnDfLkLsFZMlno+JfP/5RxrB7bs1gApSVT3Q1Lu4B1+IC9/Z7PsoCRzlqe9nlstl/6 P9L1LcSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tn3OH-00000001hF7-1W89; Tue, 25 Feb 2025 22:27:01 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tn3Mk-00000001gt9-0Qez for linux-arm-kernel@lists.infradead.org; Tue, 25 Feb 2025 22:25:27 +0000 Received: from [10.137.184.60] (unknown [131.107.160.188]) by linux.microsoft.com (Postfix) with ESMTPSA id 1BF1D203CDFE; Tue, 25 Feb 2025 14:25:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1BF1D203CDFE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1740522325; bh=4snbY5kKjPs+fqnW4bDVzUWCVcYb+NMujdrOx1UsTIo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=GmOF2vVuCkJZ1DfUd1ljj8/fusb2yUMbDy2WmYxFrMMfaTTzbAqkWEUBwLUg55zpF Eal2Uv7psJ6AMd7GHQIuT0F5bT24oqPS+VN9NVDy5j/15vSuizsFBxdX1p+w7B0n5d f2jfhVcFODVbMweP0SK+AakuXEGuKdQiYOukQldU= Message-ID: Date: Tue, 25 Feb 2025 14:25:24 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH hyperv-next v4 1/6] arm64: hyperv: Use SMCCC to detect hypervisor presence To: Arnd Bergmann Cc: benhill@microsoft.com, bperkins@microsoft.com, sunilmut@microsoft.com, bhelgaas@google.com, Borislav Petkov , Catalin Marinas , Conor Dooley , Dave Hansen , Dexuan Cui , Haiyang Zhang , "H. Peter Anvin" , krzk+dt@kernel.org, =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , "K. Y. Srinivasan" , Lorenzo Pieralisi , Manivannan Sadhasivam , Ingo Molnar , Rob Herring , ssengar@linux.microsoft.com, Thomas Gleixner , Wei Liu , Will Deacon , devicetree@vger.kernel.org, Linux-Arch , linux-arm-kernel@lists.infradead.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org References: <20250212014321.1108840-1-romank@linux.microsoft.com> <20250212014321.1108840-2-romank@linux.microsoft.com> <1b14e3de-4d3e-420c-819c-31ffb2d448bd@app.fastmail.com> <593c22ca-6544-423d-84ee-7a06c6b8b5b9@linux.microsoft.com> <97887849-faa8-429b-862b-daf6faf89481@app.fastmail.com> <6e4685fe-68e9-43bd-96c5-b871edb1b971@linux.microsoft.com> <14a199d8-1cf3-49bc-8e0d-92d9c8407b4f@linux.microsoft.com> <55b65ba6-4abe-478c-a173-4622c30ddd7b@app.fastmail.com> Content-Language: en-US From: Roman Kisel In-Reply-To: <55b65ba6-4abe-478c-a173-4622c30ddd7b@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250225_142526_197800_4853FD07 X-CRM114-Status: GOOD ( 26.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2/24/2025 11:24 PM, Arnd Bergmann wrote: > On Tue, Feb 25, 2025, at 00:22, Roman Kisel wrote: >> Hi Arnd, [...] > If you want to declare a uuid here, I think you should remove the > ARM_SMCCC_VENDOR_HYP_UID_HYPERV_REG_{0,1,2,3} macros and just > have UUID in normal UUID_INIT() notation as we do for > other UUIDs. I'd gladly stick to that provided I have your support of touching KVM's code! As the SMCCC document states, there shall be an UUID, and in the kernel, there would be #define ARM_SMCCC_VENDOR_KVM_UID UUID_INIT(.......) #define ARM_SMCCC_VENDOR_HYP_UID UUID_INIT(.......) Hence, the ARM_SMCCC_VENDOR_HYP_UID_*_REG_{0,1,2,3} can be removed as you're suggesting. That looks enticing enough semantically as though we're building layers from the SMCCC spec down to the "on-wire format" -- the only part that needs "deserializing" the UUID from `struct arm_smccc_res` the hypervisor returns. To add to that, anyone who wishes to implement a hypervisor for arm64 will have to use some RFC 9562-compliant UUID generating facility. Thus, the UUID predates these 4 dwords. Using UUIDs in the kernel code will relieve of the chore of figuring out the 4 dwords from the UUID. Also, for the Gunyah folks will be pretty easy to use this infra: define the UUID in the header (1 line), call the new function (1 line), done. > > If you want to keep the four 32-bit values and pass them into > arm_smccc_hyp_present() directly, I think that is also fine, > but in that case, I would try to avoid calling it a UUID. IMO, that approach provides a simplicity where anyone can see if the code is wrong from a quick glance: just compare 4 dwords. The fact that the 4 dwords form an UUID is bypassed though (as it is in the existing code). Somehow feels not spec-accurate imo. Also when I remove the UID part from the names, I'm going to have a rather weak justification as to why this is a benefit. Likely, there are two levels of improvement here: 1. Just refactor the common parts out and have `bool arm_smccc_hyp_present(u32 reg0, u32 reg1, u32 reg2, u32 reg2);` 2. Introduce the UUID usage throughout and have a spec-accurate prototype of `bool arm_smccc_hyp_present(const uuid_t *hyp_uuid);` and would be great to go for the second one :) > > How are the kvm and hyperv values specified originally? >>>From the SMCCC document it seems like they are meant to be > UUIDs, so I would expect them to be in canonical form rather > than the smccc return values, but I could not find a document > for them. For hyperv case, `uuidgen` produced the UUID and that is used. Likely the same for kvm. > > Arnd -- Thank you, Roman