[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 Tue, Jul 25, 2017 at 06:27:31PM +0300, Andrii Anisov wrote:
> On 25.07.17 17:23, Julien Grall wrote:
> >I think this is by chance rather than by design. The first
> >question to answer is why a Firmware would specify twice the same
> >memory banks? Is it valid from the specification?
> Yep, that is the question.

I beleive that all memory regions described in any memory node's reg
entries should be disjoint (i.e. should not overlap). Per IEEE-1275, reg
entries (within a node) are supposed to be disjoint, and I would expect
this requirement to extend across nodes in the case of memory nodes.

Currently, the DT spec is somewhat sparse in wording, but this can be

> >Regardless that, it looks like to me that the device-tree you give
> >to the board should not contain the memory nodes.
> The device-tree is provided by vendor in that form, and u-boot is
> theirs. It seems to me that they do not really care since the kernel
> tolerates duplication.
> >> ps. Linux kernel does tolerate duplicated memory nodes by
> >>merging memory blocks. I.e. memblock_add_range() function is
> >>commented as following:
> >>/**
> >>     * memblock_add_range - add new memblock region
> >>     * @type: memblock type to add new region into
> >>     * @base: base address of the new region
> >>     * @size: size of the new region
> >>     * @nid: nid of the new region
> >>     * @flags: flags of the new region
> >>     *
> >>     * Add new memblock region [@base,@base+@size) into @type. The new
> >>region
> >>     * is allowed to overlap with existing ones - overlaps don't affect
> >>already
> >>     * existing regions.  @type is guaranteed to be minimal (all
> >>neighbouring
> >>     * compatible regions are merged) after the addition.
> >>     *
> >>     * RETURNS:
> >>     * 0 on success, -errno on failure.
> >>     */
> IMO the function description is pretty straight-forward.
> But let us wait for device tree guys feedback.

This might be the designed of *memblock*, but that does not mean that it
is a deliberate part of the DT handling. I beleive this is simply an
implementation detail that happens to mask a DT bug.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.