[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH] xen/design: Add design for EFI dom0less system start
Hi Luca, On 07/09/2021 14:30, Luca Fancellu wrote: With my proposal, you don't know whether the binary is a kernel, ramdisk... So you wouldn't be able to recreate the compatible properly.On 7 Sep 2021, at 13:30, Julien Grall <julien@xxxxxxx> wrote: On 07/09/2021 12:51, Luca Fancellu wrote:On 7 Sep 2021, at 10:35, Julien Grall <julien@xxxxxxx> wrote: What we could do is providing a list of binaries to load and associate a key for each of them. Something like: binary=<binary> <key> binary=<binary2> <key2> .... We can then replace the property "reg" with a new property "uefi,key" that will contain the name of the binary. What do you think?Here I’m lost, because I don’t understand what we are going to do with the name of the binary.<binaryX> would be used by the UEFI stub to load the binary in memory. Each binary will have a <keyX> which helps to refer them in the Device-Tree. To give a concrete example, let say we have two dom0less domains: - DomA: 2 vCPUs, 128MB - DomB: 3 vCPUs, 512MB DomA and DomB will be using the same kernel but a different ramdisk. xen.cfg, would look like: [global] default=section1 [section1] options=console=vga,com1 com1=57600 loglvl=all noreboot kernel=vmlinuz-3.0.31-0.4-xen [domain 0 command line options] ramdisk=initrd-3.0.31-0.4-xen xsm=<filename> dtb=devtree.dtb binary=vmlinuz-guest domu-kernel binary=ramdisk-domA.img domA-ramdisk binary=ramdisk-domB.img domB-ramdisk The chosen node in the DT would look like: chosen { domU1 { compatible = "xen,domain"; #address-cells = <0x2>; #size-cells = <0x1>; memory = <0 0x8000000>; cpus = <2>; module@1 { compatible = "multiboot,kernel", "multiboot,module"; uefi,binary = "domu-kernel"; bootargs = "console=ttyAMA0 init=/bin/sh"; }; module@2 { compatible = "multiboot,ramdisk", "multiboot,module"; uefi,binary = "domA-ramdisk"; }; }; domU2 { compatible = "xen,domain"; #address-cells = <0x3>; #size-cells = <0x1>; memory = <0 0x20000000>; cpus = <3>; module@1 { compatible = "multiboot,kernel", "multiboot,module"; uefi,binary = "domu-kernel"; bootargs = "console=ttyAMA0 init=/bin/sh"; }; module@2 { compatible = "multiboot,ramdisk", "multiboot,module"; uefi,binary = "domA-ramdisk"; }; }; }; With this approach, the change is quite minimal to move between an classic U-boot boot and EFI boot.Ok now I see, yes this approach can work and can save some code, in the current code we have that if a "multiboot,module” is found in the dtb, the Xen EFI configuration file is skipped, but if we use the module@XX {} without the compatible it can work, the UEFI stub will load the binary and update all the needed properties (compatible, reg). But the behavior of the UEFI stub can be modified. We could say that if there is a "xen,domain" then use the configuration file to fetch the binaries. Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |