| Message ID | e1d07b26a92a45ed387594dd789453def1ef1eb2.1743678257.git-series.marmarek@invisiblethingslab.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Several CI cleanups and improvements, plus yet another new runner | expand |
On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote: > It fails on larger initramfs (~250MB one) and sometimes even smaller > depending on memory size/memory map, let Linux do it. Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better approach be to use a better compressing algorithm, which simply as a side effect would keep grub from decompressing it, while at the same time moving farther away from any critical boundaries? Jan
On Thu, Apr 03, 2025 at 01:29:16PM +0200, Jan Beulich wrote: > On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote: > > It fails on larger initramfs (~250MB one) and sometimes even smaller > > depending on memory size/memory map, let Linux do it. > > Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better approach > be to use a better compressing algorithm, which simply as a side effect > would keep grub from decompressing it, while at the same time moving > farther away from any critical boundaries? That should also make the test faster (if it's a significant difference). OTOH likely we wouldn't have found the issue with map_pages_to_xen().
On 03/04/2025 12:29 pm, Jan Beulich wrote: > On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote: >> It fails on larger initramfs (~250MB one) and sometimes even smaller >> depending on memory size/memory map, let Linux do it. > Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better approach > be to use a better compressing algorithm, which simply as a side effect > would keep grub from decompressing it, while at the same time moving > farther away from any critical boundaries? Yes and no. This is going to change anyway when I (or a delgee) moves initrd generation from the test step itself into the test artefacts repo. Switching to a slower algorithm will impact every test step right now. Real systems doesn't see this in general, because it there's an uncompressed microcode container at the front, and it's not identified as being compressed at all. I'd prefer to stick with Marek's patch in the short term. ~Andrew
On 03.04.2025 13:39, Andrew Cooper wrote: > On 03/04/2025 12:29 pm, Jan Beulich wrote: >> On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote: >>> It fails on larger initramfs (~250MB one) and sometimes even smaller >>> depending on memory size/memory map, let Linux do it. >> Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better approach >> be to use a better compressing algorithm, which simply as a side effect >> would keep grub from decompressing it, while at the same time moving >> farther away from any critical boundaries? > > Yes and no. > > This is going to change anyway when I (or a delgee) moves initrd > generation from the test step itself into the test artefacts repo. > > Switching to a slower algorithm will impact every test step right now. > > Real systems doesn't see this in general, because it there's an > uncompressed microcode container at the front, and it's not identified > as being compressed at all. > > I'd prefer to stick with Marek's patch in the short term. Fair enough. Jan
On Thu, 2 Apr 2025, Marek Marczykowski-Górecki wrote: > It fails on larger initramfs (~250MB one) and sometimes even smaller > depending on memory size/memory map, let Linux do it. > > Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> I believe this is the default with U-Boot anyway, if I remember right. Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > --- > automation/scripts/qubes-x86-64.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh > index f27296445901..8e78b7984e98 100755 > --- a/automation/scripts/qubes-x86-64.sh > +++ b/automation/scripts/qubes-x86-64.sh > @@ -248,7 +248,7 @@ CONTROLLER=control@thor.testnet > echo " > multiboot2 (http)/gitlab-ci/xen $CONSOLE_OPTS loglvl=all guest_loglvl=all dom0_mem=4G console_timestamps=boot $extra_xen_opts > module2 (http)/gitlab-ci/vmlinuz console=hvc0 root=/dev/ram0 earlyprintk=xen > -module2 (http)/gitlab-ci/initrd-dom0 > +module2 --nounzip (http)/gitlab-ci/initrd-dom0 > " > $TFTP/grub.cfg > > echo "#!ipxe > -- > git-series 0.9.1 >
diff --git a/automation/scripts/qubes-x86-64.sh b/automation/scripts/qubes-x86-64.sh index f27296445901..8e78b7984e98 100755 --- a/automation/scripts/qubes-x86-64.sh +++ b/automation/scripts/qubes-x86-64.sh @@ -248,7 +248,7 @@ CONTROLLER=control@thor.testnet echo " multiboot2 (http)/gitlab-ci/xen $CONSOLE_OPTS loglvl=all guest_loglvl=all dom0_mem=4G console_timestamps=boot $extra_xen_opts module2 (http)/gitlab-ci/vmlinuz console=hvc0 root=/dev/ram0 earlyprintk=xen -module2 (http)/gitlab-ci/initrd-dom0 +module2 --nounzip (http)/gitlab-ci/initrd-dom0 " > $TFTP/grub.cfg echo "#!ipxe
It fails on larger initramfs (~250MB one) and sometimes even smaller depending on memory size/memory map, let Linux do it. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- automation/scripts/qubes-x86-64.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)