Xen-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Michal Orzel <michal.orzel@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>
Subject: Re: [PATCH] xen/arm: domain_build.c: Use hwdom instead of dom0 where applicable
Date: Wed, 4 Nov 2026 01:58:21 +0000	[thread overview]
Message-ID: <87jymtnyro.fsf@epam.com> (raw)
In-Reply-To: <20261103164624.195576-1-michal.orzel@amd.com> (Michal Orzel's message of "Tue, 3 Nov 2026 17:46:24 +0100")

Hi Michal,

Michal Orzel <michal.orzel@amd.com> writes:

> Since commit 52cb53f1816a ("xen/arm: dom0less hwdom construction"),
> construct_hwdom() and the helpers it relies on (allocate_memory_11(),
> prepare_dtb_hwdom(), handle_node(), find_gnttab_region(), etc.) are used
> not only for the regular dom0 but also for a hardware domain created by
> dom0less. Many comments and names on this path still refer to dom0, which
> is misleading.
>
> No functional change other than the panic messages.
>
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

> ---
> This is just the cleanup for one file with the most number of occurences that
> I decided to do in the free time after reviewing latest DOM0_BOOT changes. Other
> files also need such cleanup on Arm.
> ---
>  xen/arch/arm/domain_build.c | 44 ++++++++++++++++++-------------------
>  1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 1ee1f1f6a733..606e85818eb4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -100,7 +100,7 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
>  #endif
>  
>  /*
> - * Amount of extra space required to dom0's device tree. This covers
> + * Amount of extra space required to hwdom's device tree. This covers
>   * nodes generated by Xen, which are not directly copied from the host DTB.
>   * It is calculated as:
>   *  - Space for /hypervisor node (128 bytes).
> @@ -111,15 +111,15 @@ int __init parse_arch_dom0_param(const char *s, const char *e)
>   *    plus the appendage to the main /memory node (NR_SHMEM_BANKS * (160 + 16)
>   *    bytes). This overhead is dropped when CONFIG_STATIC_SHM is disabled.
>   */
> -#define DOM0_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry) + \
> -                             (NR_MEM_BANKS * 16) +                    \
> -                             (IS_ENABLED(CONFIG_STATIC_SHM) ?         \
> -                              (NR_SHMEM_BANKS * (160 + 16)) : 0))
> +#define HWDOM_FDT_EXTRA_SIZE (128 + sizeof(struct fdt_reserve_entry) + \
> +                              (NR_MEM_BANKS * 16) +                    \
> +                              (IS_ENABLED(CONFIG_STATIC_SHM) ?         \
> +                               (NR_SHMEM_BANKS * (160 + 16)) : 0))
>  
>  paddr_t __init hwdom_get_fdt_alloc_size(void)
>  {
>      if ( acpi_disabled )
> -        return fdt_totalsize(device_tree_flattened) + DOM0_FDT_EXTRA_SIZE;
> +        return fdt_totalsize(device_tree_flattened) + HWDOM_FDT_EXTRA_SIZE;
>  
>      return ACPI_DOM0_FDT_MIN_SIZE;
>  }
> @@ -175,7 +175,7 @@ static bool __init insert_11_bank(struct domain *d,
>  
>      res = guest_physmap_add_page(d, _gfn(mfn_x(smfn)), smfn, order);
>      if ( res )
> -        panic("Failed map pages to DOM0: %d\n", res);
> +        panic("Failed map pages to %pd: %d\n", d, res);
>  
>      kinfo->unassigned_mem -= size;
>  
> @@ -245,19 +245,19 @@ fail:
>   *
>   * Requirements:
>   *
> - * 1. The dom0 kernel should be loaded within the first 128MB of RAM. This
> + * 1. The hwdom kernel should be loaded within the first 128MB of RAM. This
>   *    is necessary at least for Linux zImage kernels, which are all we
>   *    support today.
> - * 2. We want to put the dom0 kernel, ramdisk and DTB in the same
> + * 2. We want to put the hwdom kernel, ramdisk and DTB in the same
>   *    bank. Partly this is just easier for us to deal with, but also
>   *    the ramdisk and DTB must be placed within a certain proximity of
>   *    the kernel within RAM.
> - * 3. For dom0 we want to place as much of the RAM as we reasonably can
> + * 3. For hwdom we want to place as much of the RAM as we reasonably can
>   *    below 4GB, so that it can be used by non-LPAE enabled kernels (32-bit).
> - * 4. Some devices assigned to dom0 can only do 32-bit DMA access or
> + * 4. Some devices assigned to hwdom can only do 32-bit DMA access or
>   *    even be more restricted. We want to allocate as much of the RAM
>   *    as we reasonably can that can be accessed from all the devices..
> - * 5. For 32-bit dom0 the kernel must be located below 4GB.
> + * 5. For 32-bit hwdom the kernel must be located below 4GB.
>   * 6. We want to have a few largers banks rather than many smaller ones.
>   *
>   * For the first two requirements we need to make sure that the lowest
> @@ -293,7 +293,7 @@ fail:
>   * to be allocated in the low mem. Then for subsequent allocation, we
>   * initially allocate memory only from low mem. Once that runs out out
>   * (as described above) we allow higher allocations and continue until
> - * that runs out (or we have allocated sufficient dom0 memory).
> + * that runs out (or we have allocated sufficient hwdom memory).
>   */
>  static void __init allocate_memory_11(struct domain *d,
>                                        struct kernel_info *kinfo)
> @@ -311,7 +311,7 @@ static void __init allocate_memory_11(struct domain *d,
>      unsigned int bits;
>  
>      /*
> -     * TODO: Implement memory bank allocation when DOM0 is not direct
> +     * TODO: Implement memory bank allocation when hwdom is not direct
>       * mapped
>       */
>      BUG_ON(!is_domain_direct_mapped(d));
> @@ -409,8 +409,8 @@ static void __init allocate_memory_11(struct domain *d,
>  
>      if ( kinfo->unassigned_mem )
>          /* Don't want format this as PRIpaddr (16 digit hex) */
> -        panic("Failed to allocate requested dom0 memory. %ldMB unallocated\n",
> -              (unsigned long)kinfo->unassigned_mem >> 20);
> +        panic("Failed to allocate requested %pd memory. %ldMB unallocated\n",
> +              d, (unsigned long)kinfo->unassigned_mem >> 20);
>  
>      for( i = 0; i < mem->nr_banks; i++ )
>      {
> @@ -516,7 +516,7 @@ static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
>           * * remove bootargs, linux,uefi-system-table,
>           *   linux,uefi-mmap-start, linux,uefi-mmap-size,
>           *   linux,uefi-mmap-desc-size, and linux,uefi-mmap-desc-ver
> -         *   (since EFI boot is not currently supported in dom0).
> +         *   (since EFI boot is not currently supported in hwdom).
>           */
>          if ( dt_node_path_is_equal(node, "/chosen") )
>          {
> @@ -1544,7 +1544,7 @@ static int __init handle_node(struct domain *d, struct kernel_info *kinfo,
>  
>      /*
>       * Even if the IOMMU device is not used by Xen, it should not be
> -     * passthrough to DOM0
> +     * passthrough to hwdom.
>       */
>      if ( device_get_class(node) == DEVICE_IOMMU )
>      {
> @@ -1695,7 +1695,7 @@ static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info *kinfo)
>      kinfo->phandle_intc = dt_interrupt_controller->phandle;
>      fdt = device_tree_flattened;
>  
> -    new_size = fdt_totalsize(fdt) + DOM0_FDT_EXTRA_SIZE;
> +    new_size = fdt_totalsize(fdt) + HWDOM_FDT_EXTRA_SIZE;
>      kinfo->fdt = xmalloc_bytes(new_size);
>      if ( kinfo->fdt == NULL )
>          return -ENOMEM;
> @@ -1764,7 +1764,7 @@ static void __init find_gnttab_region(struct domain *d,
>          gnttab_resource_max_frames(d, XENMEM_resource_grant_table_id_shared);
>  
>      /*
> -     * The region used by Xen on the memory will never be mapped in DOM0
> +     * The region used by Xen on the memory will never be mapped in hwdom
>       * memory layout. Therefore it can be used for the grant table.
>       *
>       * Only use the text section as it's always present and will contain
> @@ -1776,7 +1776,7 @@ static void __init find_gnttab_region(struct domain *d,
>  
>  #ifdef CONFIG_ARM_32
>      /*
> -     * The gnttab region must be under 4GB in order to work with DOM0
> +     * The gnttab region must be under 4GB in order to work with hwdom
>       * using short page table.
>       * In practice it's always the case because Xen is always located
>       * below 4GB, but be safe.
> @@ -1941,7 +1941,7 @@ int __init construct_hwdom(struct kernel_info *kinfo,
>              return rc;
>      }
>  
> -    /* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
> +    /* Map extra GIC MMIO, irqs and other hw stuffs to hwdom */
>      rc = gic_map_hwdom_extra_mappings(d);
>      if ( rc < 0 )
>          return rc;

-- 
WBR, Volodymyr

      parent reply	other threads:[~2026-11-04  1:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 16:46 [PATCH] xen/arm: domain_build.c: Use hwdom instead of dom0 where applicable Michal Orzel
2026-11-03 20:45 ` Stefano Stabellini
2026-11-04  1:58 ` Volodymyr Babchuk [this message]

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=87jymtnyro.fsf@epam.com \
    --to=volodymyr_babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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