Re: [Xen-devel] REGRESSION: Xen 4.13 RC5 fails to bootstrap Dom0 on ARM

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
<sstabellini@xxxxxxxxxx> wrote:
>
> On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> > Hi!
> >
> > it appears that something has broken in 4.13 RC5 so that
> > I'm now getting the following on ARM (full logs are attached).
> >
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) Failed to allocate requested dom0 memory. 672MB unallocated
> > (XEN) ****************************************
> >
> > My GRUB boot sequence hasn't changed:
> >
> > xen_hypervisor /boot/xen.efi console=dtuart   dom0_mem=1024M,max:1024M
> > dom0_max_vcpus=1 dom0_vcpus_pin
>
> FYI we don't actually support the ",max:1024M" part of the dom0_mem
> argument on ARM. On ARM, it should just be:
>
>   dom0_mem=1024M

I tried with just dom0_mem=1024M and it is the same result -- can't boot.

> > xen_module /boot/kernel console=hvc0 root=(hd1,gpt1)/rootfs.img text
> > devicetree (hd1,gpt4)/eve.dtb
> > xen_module (hd1,gpt1)/initrd.img
> >
> > In fact, if I use Xen 4.12 instead of 4.13 -- everything seems to work
> > as it used to.
>
> I spoke too early: I am unable to reproduce it on my end. On what
> platforms did you see this error? Was it the HiKey?

Yup. It is HiKey.

> Could you please
> post the devicetree that you are using (eve.dtb from this example)?

Looks like you've found it ;-) Btw, can you please send me the device
tree with which you're booting fine? I can try that very quickly.

> If the dts is this one: 
> https://github.com/lf-edge/eve/blob/master/conf/eve.dts
> then I might have an idea.

Yup. That's the one.

> In Xen 4.13 we introduced support for
> reserved-memory. It looks like the HiKey has a few reserved-memory
> regions and I wonder if that is the problem. Could you please remove the
> whole "reserved-memory" node and try again to see if that is the issue?

Will do tomorrow (but I'd also appreciate getting your devicetree).

> Also looking at eve.dts above, I am a bit puzzled because the memory
> node is:
>
>     memory@0 {
>                 device_type = "memory";
>                 reg = <0x0 0x0 0x0 0x5e00000 0x0 0x5f00000 0x0 0x1000 0x0 
> 0x5f02000 0x0 0xefd000 0x0 0x6e00000 0x0 0x60f000 0x0 0x7410000 0x0 
> 0x1aaf0000 0x0 0x22000000 0x0 0x1c000000>;
>         };
>
> If I sum all the memory sizes together I get 0x3ddfd000 which is 990M.
> If so, I wonder how you could boot succesfully with dom0_mem=1024M even
> on Xen 4.12... :-?

That is a very interesting observation indeed! I actually don't
remember where that device tree came from, but I think it was from one
of the Linaro sites.

> If we look at ramoops@21f00000 under reserved-memory:
>
>                 ramoops@21f00000 {
>                         record-size = <0x20000>;
>                         compatible = "ramoops";
>                         console-size = <0x20000>;
>                         reg = <0x0 0x21f00000 0x0 0x100000>;
>                         ftrace-size = <0x20000>;
>                 };
>
> the memory range "0x0 0x21f00000 0x0 0x100000" is supposed to fall in
> any of the memory ranges of the memory node (the ones I copy/pasted
> above). But actually it doesn't. That is a device tree error.
>
> Maybe you could try booting on the HiKey changing

Btw, speaking of which: silly question -- it seems I can boot Linux just
fine with this device tree and it appears functional with one caveat: try
as hard as I may I can't get the console output (note that Xen has no
problem outputting to the console -- well at least until it crashes and
with Xen 4.12 Linux is very happy using hvc0).

Any chance you can suggest what would be a reasonable setting
for booting a pure Linux kernel when it comes to console output?
That way, at least, I can do some additional experimenting.

> the device tree so that the
> memory node includes the ramoops range, like this:
>
>     memory@0 {
>                 device_type = "memory";
>                 reg = <0x0 0x0 0x0 0x5e00000 0x0 0x5f00000 0x0 0x1000 0x0 
> 0x5f02000 0x0 0xefd000 0x0 0x6e00000 0x0 0x60f000 0x0 0x7410000 0x0 
> 0x1aaf0000 0x0 0x21f00000 0x0 0x100000 0x0 0x22000000 0x0 0x1c000000>;
>         };
>
> (Note that I added "0x0 0x21f00000 0x0 0x100000" to the list of ranges in 
> order.)
>
> Let me know!

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