On Tue, 8 Jul 2025, Alejandro Vallejo wrote:
> ... based on CONFIG_X86. x86 won't depend on it, and it'll only be used
> by the domain builder in common/device-tree/
>
> Moving it to an arch-specific subfield (as introduced in a later patch)
> is unwieldy, because all other arches depend on it.
>
> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
> ---
> My expectation is to remove the field altogether after we reach full
> integration in common code, by deducing this boolean from the domain
> capabilities given in the "capabilities" prop.
>
> That's not something I'm working at the moment though.
Merging, moving, and generalizing code is something we have learned from
experience often requires a few incremental steps. I believe this is
acceptable as a first step.
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/include/xen/bootfdt.h | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/xen/include/xen/bootfdt.h b/xen/include/xen/bootfdt.h
> index 236b456dd2..7f49d0ccdd 100644
> --- a/xen/include/xen/bootfdt.h
> +++ b/xen/include/xen/bootfdt.h
> @@ -96,16 +96,18 @@ struct shared_meminfo {
> struct shmem_membank_extra extra[NR_SHMEM_BANKS];
> };
>
> -/*
> - * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
> - * The purpose of the domU flag is to avoid getting confused in
> - * kernel_probe, where we try to guess which is the dom0 kernel and
> - * initrd to be compatible with all versions of the multiboot spec.
> - */
> #define BOOTMOD_MAX_CMDLINE 1024
> struct boot_module {
> boot_module_kind kind;
> +#ifndef CONFIG_X86
> + /*
> + * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
> + * The purpose of the domU flag is to avoid getting confused in
> + * kernel_probe, where we try to guess which is the dom0 kernel and
> + * initrd to be compatible with all versions of the multiboot spec.
> + */
> bool domU;
> +#endif
> paddr_t start;
> paddr_t size;
> };
> --
> 2.43.0
>