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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.04.2021 21:23, Christopher Clark wrote:
> On Tue, Mar 30, 2021 at 7:31 AM Jan Beulich <jbeulich@xxxxxxxx> 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

In a separate context (parallel ongoing discussion under "multiboot2
and module2 boot issues via GRUB2") Andrew raised the (imo valid)
point of this getting the more fragile the more modules there are.

> - 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

"Need to match" meaning what? You don't clarify how boot loader
config and device tree blob are meant to be kept in sync.

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

I'm not concerned of you breaking anything. I merely raised a possible
scalability issue of your current proposal.

Jan