[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Duplicated memory node in the Device-Tree (WAS [XEN] Re: Duplicated memory nodes cause the BUG())
On 25/07/17 17:02, Andrii Anisov wrote: > Hello Julien, > > > On 25.07.17 18:44, Julien Grall wrote: >> I have seen work on this board for the past year and it is the first >> time I have seen a complain about memory overlap. So why this sudden >> change? > It just an approach change. I'm cleaning up nits for the board. > >> Is that a comment from the vendor or your guess? > It is my impression. > But yes, it could be worth to ask them why do they hardcode the memory > layout in their u-boot but stuff the dts with number of memory nodes. > Actually from the beginning of our time for this board the solution > was merging all memory description nodes in one in a dts for XEN, like > [1]. So u-boot runtime updates to the dtb were just ignored. > >> You need to differentiate the device-tree spec itself and Linux >> implementation. memblock is something common to all architecture. It >> does not mean it is something valid to do. > That is why I asked for an advice. > > [1] > https://github.com/xen-troops/meta-demo/blob/master/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas/r8a7795-salvator-x-xen.dts#L61 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. 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. Hitting a BUG() is not a user friendly thing to do, so should be fixed. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |