Re: [xen-unstable-smoke test] 155612: regressions - FAIL

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Sat, 10 Oct 2020, Julien Grall wrote:
> Hi,
> 
> On 10/10/2020 12:42, Trammell Hudson wrote:
> > On Friday, October 9, 2020 10:27 PM, Andrew Cooper
> > <andrew.cooper3@xxxxxxxxxx> wrote:
> > > [...]
> > > Looks like arm64 is crashing fairly early on boot.
> > > 
> > > This is probably caused by "efi: Enable booting unified
> > > hypervisor/kernel/initrd images".
> > 
> > Darn it.  I'm working out how to build and boot qemu aarch64 so
> > that I can figure out what is going on.
> 
> FWIW, in OSSTest, we are chainloading Xen from GRUB. I have tried to
> chainloading on QEMU but couldn't get to work so far (even without your
> series).
> 
> Although, I have no trouble to boot using the GRUB way (i.e. via multiboot).

It took me a while to set it up, but now I have a test environment based
on RPi4 where I can chainload Xen from Grub EFI and boot successfully up
until the rootfs (I don't have a rootfs setup correctly yet, so it
breaks with the usual "Cannot open root device".) Which means I can get
both Xen and the Dom0 kernel to boot.

I hope it will be useful in the future, but in this case it didn't help
because I get the same behavior with and without Trammell's patches. For
me the chainload boot doesn't break.

Could it be down to the Grub version in-use? I am using UBoot EFI to
load Grub, but I doubt that could be a meaningful difference.


> > Also, I'm not sure that it is possible to build a unified arm
> > image right now; objcopy (and all of the obj* tools) say
> > "File format not recognized" on the xen.efi file.  The MZ file
> > is not what they are expecting for ARM executables.
> 
> IIUC, you are trying to add section into the EFI binary and not the ELF. Is it
> correct?
> 
> I don't know what x86 is doing but for Arm, xen.efi (and Linux Image) is
> custom built.

Specifically, see:

xen/arch/arm/arm64/head.S:efi_head


> So it may lack information to be recognized by objdump.
> 
> My knowledge of objdump is fairly limited. If you are interested to fix it,
> then I would suggest to ask the binutils community what they expect.
> 
> We could then adapt so objdump can recognize it.