Re: [PATCH 0/2] Introducing hyperlaunch capability design (formerly: DomB mode of dom0less)

[Christopher Clark <christopher.w.clark@gmail.com>]

On Tue, Mar 30, 2021 at 7:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.03.2021 04:56, Daniel P. Smith wrote:
> > To assist in reading, please find attached rendered copies of the design
> > docs. It should be noted that due to poor rendering by pandoc, we forced
> > the tables to stay as ASCII tables in the patches whereas the attached
> > docs have the tables rendered properly by rst2pdf.
>
> In section 3.6 I found "As a result, on x86 the hyperlaunch capability does
> not rely on nor preclude any specific BIOS boot protocol, i.e legacy BIOS
> boot or UEFI boot. The only requirement is that the boot loader supports
> the Multiboot2 (MB2) protocol." I'm afraid the two sentences contradict
> one another, as UEFI on its own doesn't provide MB2 functionality. It is
> my understanding that you don't require this anyway - what you need is a
> way to load modules beyond just Dom0 kernel and an initrd.

Thanks - we'll amend the doc. Given the already sizeable scope of the
project, our current approach for host UEFI is to recommend use of
GRUB.efi to load Xen and the initial domains via the multiboot2 method.

> I'm also struggling to see how you mean to associate the (MB2) modules
> passed to Xen with the individual functions. I.e. I don't see how it will
> be ensure that the embedded mb-index is in sync with the order or modules
> actually supplied.

To make sure I'm following the concern raised here, my understanding is:

- the multiboot module list is ordered and stable, so that the order
  that the bootloader provides the modules in is the same order in which
  Xen receives them, in the multiboot data structure, so the modules can
  be referenced by an index into that list

- for a given Launch Control Module file (expressed in a Device Tree, as
  described in our second design document), the provided multiboot
  modules will need to match, both in type (kernel, ramdisk, microcode,
  xsm policy) and order

- we think that at some point the LCM will end up being dynamically
  generated by an enlightened bootloader, assembling it from the
  bootloader config file, which will list the modules and their types

> As to modules - iirc there are placement restrictions by at least some
> boot loaders (below 4Gb). If that's correct, do you have any thoughts
> towards dealing with the limited space available to hold these modules?
> I've seem systems with lots of memory, but with as little as just 1Gb
> below the 4Gb boundary.

At this point, I don't think that we'll break anything that currently
works, and that hardware or platform limitations can always constrain
what is deployable.

Christopher