[PATCH v6 01/11] xen: Conditionally compile out the boot_module.domU

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

... 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@xxxxxxx>
---
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.
---
 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