[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v1 1/3] xen/dom0less: introduce free_phandle in struct kernel_info
- To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Mon, 20 Apr 2026 09:26:23 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=gmail.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uB6k0kOtErN3VP+hR2720UAh2VmSDTlX3y1KH48oS/8=; b=fDkZkH+7HQiChxe7yGEmD52YQlTLH6iyIhRs/nzRcvYCGKaQP9QEQA+nhxh/OLLofzuj/KjpLnyhYGzJQk71whwXNTPqz3rUZRsR8M5xb4qMo5urpNWj4EMv0AzDHOax4bdUhs4Lb5e7OWj0EEtpN+2VkiQ3QL4btJcO3CNXYbuRuebUkQ/7GS21mEfFmmn3ufBZQleDkF+ju5vIRO7Z7iqVuz94VSyie46HjcOatfuw0PfRrR3mtk35mfzC1lKEdeqqBHMKMi/IU3mg0TOLG2xjaDlNaNfQeWLCbvhy3dp1EzS6pdTTRHom0xUOi8cPNONv6bbd0eaLqhRhCSqB7w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Tik8JBeUG8YbQS/ClNrKXNYYrp+nV4hSFmO5qm70FctqPryP7CRnhXCsrc0p9Y2GD3JTpbh3Ju9iedvrkgyMLIFx50fmL8L3NYFRwbK6vLeak94TIKjCuk4zuEkVJIyn/J6EyI8UCQ9XHV20rhTYFB2ru4stIQMJVhBf99TbuvGb9acA33B0OEwHtQNhcxTZasiOVKPFwbDQA9aM0isDQ6AeA4/Awga8L4F3v7lg3C8rfqOexFF4Qwnjl5dhdIFizqiCxXL56w/+Op2d4Mha8SnSbNV08L63of5dbSnoZe3MkmGkb+lu7oahPRPWE4XvpF4ODVq2SNC3+nrZvxdqXw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Mon, 20 Apr 2026 07:26:50 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 16/04/2026 16:20, Oleksii Kurochko wrote:
> There are cases where it is necessary to know the next available phandle
> number in order to generate phandles for guest device nodes.
>
> When a partial FDT (pfdt) is provided, special care is needed during
> initialization of free_phandle, as the pfdt may already contain a dummy
> interrupt controller node with a phandle assigned to it. free_phandle
> must therefore be initialized to one past the highest phandle already
> present in the pfdt, to avoid collisions.
>
> Since free_phandle may be needed for the very first guest node generated,
I would prefer next_phandle rather than free_phandle given that it always holds
the *next* phandle to be allocated. Free is implied.
> domain_handle_dtb_boot_module() is moved earlier in prepare_dtb_domU().
> The new call site also aligns better with the existing comment stating
> that domain_handle_dtb_boot_module() must be called before the rest of
> the device tree is generated.
>
> Introduce get_next_free_phandle() to ensure that phandles allocated for
The name is a bit confusing. It reads as "get the next one after the current
free phandle" but it actually returns the current value of free_phandle and post
increments it. Let's call it alloc_phandle(). This will also make it clear to
use the return value of this function instead of directly kinfo value.
Other than that, all good.
~Michal
|
