From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [Xen-devel] Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG()) Date: Tue, 25 Jul 2017 19:02:17 +0100 Message-ID: <041fe162-8944-5c1b-364a-940d21a3c69e@arm.com> References: <835d808c-9d5e-2dc0-6cf9-8fbecdc49914@epam.com> <6d1fb061-03b0-3b58-e70a-3c0e0777d8d7@arm.com> <7c1c8267-a065-f8ee-7e20-147d722c59be@arm.com> <6e9456a3-7f0f-72e5-b4be-2bd51939d850@epam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Stefano Stabellini , Andrii Anisov Cc: Andrew Cooper , xen-devel , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Wei Liu , Tim Deegan , Ian Jackson , George Dunlap , Jan Beulich List-Id: devicetree@vger.kernel.org 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html