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

[Julien Grall <julien@xxxxxxx>]

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.

Cheers,

--
Julien Grall

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