Re: [PATCH 2/2] arm/efi: Use dom0less configuration when using EFI boot

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 16 Sep 2021, Jan Beulich wrote:
> On 16.09.2021 17:07, Luca Fancellu wrote:
> > I explain here my understanding on dom0less, this feature is used to start 
> > domUs at
> > Xen boot in parallel, the name is misleading but it doesn’t require dom0 to 
> > be absent.
> > 
> > So if you have a dom0 kernel embed in the image, it's completely fine to 
> > start it and it 
> > doesn’t have to be skipped.
> > 
> > Here the possible user cases:
> > 1) start only dom0 [dom0 modules on xen.cfg or embedded in Xen image]
> > 2) start only domUs, true dom0less [no dom0 modules on xen.cfg or embedded 
> > in Xen image, domUs on DT]
> > 3) start dom0 and domUs [(dom0 modules on xen.cfg or embedded in Xen image) 
> > and domUs on DT]
> 
> If that's the intention - fine. Stefano?

What do you mean by dom0 modules embedded in the Xen image? I am not
familiar with it, but I imagine it doesn't involve any multiboot,module
nodes in device tree, right?

Putting aside "dom0 modules embedded in Xen image" that I didn't fully
understand, there are three ways to load Dom0:

- dom0 kernel (and ramdisk, optional) on xen.cfg
- dom0 kernel (and ramdisk, optional) on device tree using the "reg" property
- dom0 kernel (and ramdisk, optional) on device tree using the "uefi,binary" 
property

Then, the other use cases are:

- true dom0less, domUs on device tree using the "reg" property
- true dom0less, domUs on device tree using the "uefi,binary" property

And of course all the possible combinations between Dom0 and DomU
loading.


Currently, patch #1 checks for the presence of a Dom0 kernel node and, if
present, it decides not to proceed with xen.cfg. So if the Dom0 kernel
node is *not* present, efi_arch_use_config_file returns true.

However, this could be a true dom0less configuration without any Dom0
kernel. If so, you might not want to load xen.cfg at all because it is
not needed. In a true dom0less configuration, we probably want
efi_arch_use_config_file to return false.


In general, loading xen.cfg or not loading xen.cfg doesn't seem like it
should be dependent on whether there is or there is not a dom0 kernel
node in device tree. I think there are too many possible combinations to
guess correctly based on the presence of the dom0 kernel node. Instead,
I think it would be better to have an explicit flag.

Today, if a "multiboot,module" node is present, efi_arch_use_config_file
returns false. So I suggested to extend it so that if a
"multiboot,module" node is present we look into a specific
xen.cfg-loading property and if present return true otherwise false.
This way, we are backward compatible.