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 :-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html