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.
