On Tue, 25 Jul 2017, Julien Grall wrote: > 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. That's true. It does not make sense to do this until we get rid of the Xen specific R-Car device tree on the wiki. > [1] > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X -- 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
