Re: [Xen-devel] bug: unable to LZ4 decompress ub1910 installer kernel when launching domU

[Jeremi Piotrowski <jeremi.piotrowski@xxxxxxxxx>]

On Tue, Dec 03, 2019 at 09:02:18AM +0100, Jan Beulich wrote:
> On 01.12.2019 18:47, Jeremi Piotrowski wrote:
> > On Thu, Oct 24, 2019 at 10:12:19AM +0200, Jan Beulich wrote:
> >> On 23.10.2019 22:33, Pry Mar wrote:
> >>> Hello xen-devel,
> >>>
> >>> https://paste.debian.net/plain/1109374
> >>>
> >>> shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
> >>> to launch a pv install of the newly released ub1910. The source is a
> >>> block-attached ISO and the kernel/ramdisk was copied off locally.
> >>
> >> Would you please increase verbosity (xl -vvv create ...) such that we
> >> can see what exactly the decompression code doesn't like about this
> >> kernel image?
> > 
> > I stumbled across the same issue, below is the xl -vvvv create output.
> > 
> > Parsing config from ubuntu.cfg
> > libxl: debug: libxl_create.c:1693:do_domain_create: Domain 0:ao 
> > 0x55a598e77190: create: how=(nil) callback=(nil) poller=0x55a598e74040
> > libxl: debug: libxl_device.c:397:libxl__device_disk_set_backend: Disk 
> > vdev=xvda spec.backend=unknown
> > libxl: debug: libxl_device.c:358:disk_try_backend: Disk vdev=xvda, backend 
> > phy unsuitable due to format qcow2
> > libxl: debug: libxl_device.c:431:libxl__device_disk_set_backend: Disk 
> > vdev=xvda, using backend qdisk
> > libxl: debug: libxl_create.c:1018:initiate_domain_create: Domain 11:running 
> > bootloader
> > libxl: debug: libxl_bootloader.c:334:libxl__bootloader_run: Domain 11:no 
> > bootloader configured, using user supplied kernel
> > libxl: debug: libxl_event.c:689:libxl__ev_xswatch_deregister: watch 
> > w=0x55a598e827a8: deregister unregistered
> > domainbuilder: detail: xc_dom_allocate: cmdline="", features=""
> > libxl: debug: libxl_dom.c:799:libxl__build_pv: pv kernel mapped 0 path 
> > /tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic
> > domainbuilder: detail: xc_dom_kernel_file: 
> > filename="/tank/xenscratch/ubuntu/vmlinuz-5.3.0-23-generic"
> > domainbuilder: detail: xc_dom_malloc_filemap    : 11132 kB
> > domainbuilder: detail: xc_dom_boot_xen_init: ver 4.12, caps xen-3.0-x86_64 
> > xen-3.0-x86_32p 
> > domainbuilder: detail: xc_dom_parse_image: called
> > domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader 
> > ... 
> > domainbuilder: detail: loader probe failed
> > domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ... 
> > domainbuilder: detail: loader probe failed
> > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
> > domainbuilder: detail: LZ4 decompression error: decoding failed
> 
> This suggests that the decoding logic didn't like the input. Since as
> per the other mail manual decompression works, this will likely need
> debugging by someone able to repro.
> 
> Jan

I'm able to repro, and I isolated the code from xc_dom_bzimageloader.c,
xc_dom_decompress_lz4.c and /xen/common/lz4/decompress.c such that I can
test more easily (I'm using code from 4.12.1). I'm testing with
vmlinuz-5.3.0-23-generic installed in ubuntu-19.10.

What I see is that the code fails at the first frame at decompress.c:282
(if (unlikely((unsigned long)cpy < (unsigned long)op))).
because cpy == (op - 1).
decompress.c:265 (cpy = op + length - (STEPSIZE-4);) gets executed twice and
prints:

length=4
length=3

STEPSIZE is 8 (x86_64). So this has to fail. The STEPSIZE gave me the
idea to rebuild the code as 32-bit and decompression works correctly.

Any suggestions how to proceed?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel