[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Roman,

On 19/12/2019 00:28, Roman Shaposhnik wrote:
On Wed, Dec 18, 2019 at 2:17 PM Julien Grall <julien@xxxxxxx> wrote:

Hi Roman,

On 18/12/2019 17:03, Roman Shaposhnik wrote:
On Wed, Dec 18, 2019 at 3:50 AM Julien Grall <julien@xxxxxxx> wrote:
So -- nothing boots directly by UEFI -- everything goes through GRUB.

However, my understanding is that GRUB will detect devicetree
information provided by UEFI (even though devicetree command is
supposed to completely replace that). Hence it is possible that Linux
relies on some residuals left in memory by GRUB that Xen doesn't pay
attention to (but this is a pretty wild speculation only).

While it goes through GRUB, it is a bootloader and will just act as a
proxy for EFI. So EFI application such as Xen/Linux can still be loaded
and take advantage of runtime servies if present/implemented.

Aha! So then it depends on Xen actually using those EFI services. Which
leads to my first question:
    1. would it be possible to stay completely with just devicetrees information
        by passing efi=no-rs to Xen?
This will only disabled the runtime services (note that they are not supported on Xen on Arm today). What I described above is part of the boot services and can't be disabled.

Also, I am not entirely sure GRUB/EFI will update you device-tree to point out the memory that was carved out for things like ATF.

Looking at the DTS memory node you provided in another e-mail, it seems the memory map is slightly different.

In fact most of people on Arm are using GRUB rather than EFI directly as
this is more friendly to use.

Regarding the devicetree, Xen and Linux will completely ignore the
memory nodes in Xen if using EFI. This because the EFI memory map will
give you an overview of the platform with the EFI regions included.

Aha! So in that sense it is a bug in Xen after all, right? (that's what you're
referring to when you say you now understand what needs to get fixed).

Yes. The EFI memory map is a list of existing memory with a type associated to it (Conventional, BootServiceCodes, MemoryMappedIO...).

The OS/Hypervisor will have to go through them and check which regions are usuable. Compare to Linux, Xen has limited itself to only a few types.

However, I think we can be on a par with Linux here.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.