[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/3] xen/dom0less: introduce next_phandle in struct kernel_info
- To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Mon, 27 Apr 2026 08:50:49 +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=8pPvlkweU++pWabgv3FT1G1/MZ19OtebLT4SE6Wn7og=; b=JzeyAQPIFs3zruxG4vq60HTQkqVcxRVM5k2k3nGjg22fC6jGbTbG397I1ouqtOWEVCTP0NSrEs8hk5Ch6ltCt+WCr7zb7AlqrGfFPehGLsj0QCuk0deIWWJfI7AuK+3O5FSqo6ZKOVjM+cK7p2cyngBKPOwywyRx9Nv0EqKMoHiADZFmhtx4A0XUTQ01IttpW2OPIKCm7Nd9zRsrmUzF0q0KfbseYS3oN+++Fa9SyHclR4vKrjq0ewVFtqFpCbDdBk5RhvXeQ0QoJS6ASqNQExfsQWS/T6yL3B+epm/AJknDgJPx0aH41luZLVIOMzW++v5DsvK5gu4vK3vv3AkqNg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jmJWRaYDgIKpapCV5YIkdO7rIXuOi+LoIqJEgZ8P55NgFVRXwi0xeewHG77As/Efajdo7dR44hl80M7tt+omvCBM8YUWe7p3AneD4vj/SH7kvf+Xr4fnBHhJp7KEygOGQ3st9nPuiwx5Mmff2b4BS5JK9X48uuHBgTTYCXwZHlyoB/2vu4nOiidIu/WOlHpSpGa0O9/80Cou8h0ADajhX3/zSXbneQEg1B4uVihEiDN32tNJpszfz/lJBRUxCougHI5+PqpePGn2xEQF+ALOY8KDV3sPS6j1uv1QGSRAbRTDSXURDRtNnMcNmy9JIb3toX3ytRl9xioeFXKYT3ZVkw==
- 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: Romain Caritey <Romain.Caritey@xxxxxxxxxxxxx>, 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, 27 Apr 2026 06:51:17 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 24-Apr-26 3:36 PM, 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 next_phandle, as the pfdt may already contain a dummy
> interrupt controller node with a phandle assigned to it. next_phandle
> must therefore be initialized to one past the highest phandle already
> present in the pfdt, to avoid collisions.
>
> Since next_phandle may be needed for the very first guest node generated,
> 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 alloc_phandle() to ensure that phandles allocated for guest
> nodes do not overlap the Xen-reserved phandle range. This helper will
> be used by subsequent patches (by RISC-V at the moment).
>
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx>
~Michal
|
