Re: [Xen-devel] Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG())

[Julien Grall <julien.grall@xxxxxxx>]

On 25/07/17 18:52, Stefano Stabellini wrote:
> On Tue, 25 Jul 2017, Andrii Anisov wrote:
> > Hello Andrew,
> >
> >
> > On 25.07.17 19:23, Andrew Cooper wrote:
> > > As a general rule, Xen needs to be able to tolerate and cope with any
> > > quantity of crap described by the firmware.  On the x86 side, we have
> > > large quantities of workarounds for buggy ACPI/MP/SMBIOS tables.
> > That approach somehow covered with early mentioned options:
> >
> > On 25.07.17 15:24, Andrii Anisov wrote:
> > > * ignore next duplicating (overlapping) memory node in favor of one already
> > > in a memory banks list
> > > * merge duplicating (overlapping), even neighboring, memory banks
> > On 25.07.17 19:23, Andrew Cooper wrote:
> > > It might be the case that the best Xen can do is give up, but it should
> > > do so with a clear error message identifying what the firmware has done
> > > which is sufficiently crazy to prevent further booting.
> > We have one more option to choose for the case:
> >
> > * BUG() with clear notification at the moment we are trying to add overlapping
> > memory bank
> >
> > So what to choose?
> Certainly we need to print a clear warning.
+1 here.

> Then, we can decide whether we prefer to crash (as we do today), or
> work-around the broken device-tree. I think it would be more beneficial
> to Xen users if we tried to continue anyway, and probably the best way
> to do that would be by merging the overlapping memory regions.
> I fully understand that this is not required by the spec, but lots of
> hardware (x86 and ARM) get released every day with some sort of broken
> spec compliance. It's our job to decide on a case by case basis whether
> it makes sense for us to support these platforms anyway.
>
> In this case, the cost of supporting the Renesas R-Car Gen3 seems pretty
> limited to me. Of course, I would have to see the patch, but if we can
> make this work with limited amount of changes, very maintainable, I
> would take them. Otherwise, screw it :-)
I tend to disagree here. This is the first board were the bug occurs and 
the Device-Tree is replaceable.
Furthermore, if you look at the wikipage for Renesas R-Car on Xen (see 
[1]), a specific DT for Xen is provided.
So I can't see any reason to implement that in Xen at the moment.

Cheers,

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel