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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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 :-)

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