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, 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


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