Deprecating reserve-map in favor of properties

Deprecating reserve-map in favor of properties

[Benjamin Herrenschmidt]

Hi folks !

The reserve map is, imho, my biggest mistake when coming up with the FDT
format.

The main problem is that it doesn't survive the transition via a real
Open Firmware interface. There is no practical way to indicate reserved
regions of memory accross in that case, unless you have an OS that is
nice enough to try to keep OF alive and accomodate its advertised
"available" properties, but that's typically not the case of Linux on
ppc.

So I would like to propose that we add a new "better" way to convey
reserved memory information, via properties in the tree.

I originally though of having these in the "memory" nodes themselves but
this can be tricky on machines that have multiple nodes (ie, NUMA
generally means a memory node per NUMA node) since the reserved regions
can spawn accross nodes and I don't want to complicate FW life too much
by requiring breaking them up in that case.

So what about something at the root of the tree:

reserved-ranges: An array of ranges of reserved memory

reserved-names: A list of zero terminated strings, one for each entry in
the reserved-ranges array, providing optional "names" for the reserved
ranges.

The idea here is that we could have well defined names (using a similar
prefix we use for properties) such as linux,initrd, which indicates
clearly to the kernel that the only reason that range is reserved is
because it contains an initrd (ie, it can be freed once that's been
extracted).

It would also be generally handy in case a reserved area is meant to be
used by a specific driver, such as an in-memory framebuffer
pre-initialized by the firmware. The generic memory management code
doesn't need to know, but later on, the gfx driver can pick it up easily
provided the name is part of the binding for that device.

Any objection ? If none, I'll cook up a patch to add support for it (at
least on powerpc :-)

Cheers,
Ben.

Re: Deprecating reserve-map in favor of properties

[Kumar Gala]

On Sep 20, 2012, at 5:10 PM, Benjamin Herrenschmidt wrote:

> Hi folks !
>=20
> The reserve map is, imho, my biggest mistake when coming up with the =
FDT
> format.
>=20
> The main problem is that it doesn't survive the transition via a real
> Open Firmware interface. There is no practical way to indicate =
reserved
> regions of memory accross in that case, unless you have an OS that is
> nice enough to try to keep OF alive and accomodate its advertised
> "available" properties, but that's typically not the case of Linux on
> ppc.
>=20
> So I would like to propose that we add a new "better" way to convey
> reserved memory information, via properties in the tree.
>=20
> I originally though of having these in the "memory" nodes themselves =
but
> this can be tricky on machines that have multiple nodes (ie, NUMA
> generally means a memory node per NUMA node) since the reserved =
regions
> can spawn accross nodes and I don't want to complicate FW life too =
much
> by requiring breaking them up in that case.
>=20
> So what about something at the root of the tree:
>=20
> reserved-ranges: An array of ranges of reserved memory
>=20
> reserved-names: A list of zero terminated strings, one for each entry =
in
> the reserved-ranges array, providing optional "names" for the reserved
> ranges.
>=20
> The idea here is that we could have well defined names (using a =
similar
> prefix we use for properties) such as linux,initrd, which indicates
> clearly to the kernel that the only reason that range is reserved is
> because it contains an initrd (ie, it can be freed once that's been
> extracted).
>=20
> It would also be generally handy in case a reserved area is meant to =
be
> used by a specific driver, such as an in-memory framebuffer
> pre-initialized by the firmware. The generic memory management code
> doesn't need to know, but later on, the gfx driver can pick it up =
easily
> provided the name is part of the binding for that device.
>=20
> Any objection ? If none, I'll cook up a patch to add support for it =
(at
> least on powerpc :-)
>=20
> Cheers,
> Ben.

If you do this, please update the code in dtc/libfdt to construct the =
new nodes.  We use this in u-boot to reserve kernel, dtb, initrd, etc =
regions.  So would be nice to have drop in replacement code that could =
use same APIs if possible.

- k=

Re: Deprecating reserve-map in favor of properties

[Benjamin Herrenschmidt]

On Thu, 2012-09-20 at 20:35 -0500, Kumar Gala wrote:
> If you do this, please update the code in dtc/libfdt to construct the
> new nodes.  We use this in u-boot to reserve kernel, dtb, initrd, etc
> regions.  So would be nice to have drop in replacement code that could
> use same APIs if possible.

The kernel would of course still understand the reserve map and I don't
intend to remove it from the header immediately, so I think that can
stay.... unless we make it a function of the version.

It's non-trivial to make the same (stateless) API in libfdt deal with
setting properties. I'd rather avoid that problem initially by not
changing the blob format, keeping the reserve map around for "legacy"
purposes and simply making the kernel capable of understanding the
properties.

Cheers,
Ben.

Re: Deprecating reserve-map in favor of properties

[Grant Likely]

On Fri, Sep 21, 2012 at 12:10 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Hi folks !
>
> The reserve map is, imho, my biggest mistake when coming up with the FDT
> format.
>
> The main problem is that it doesn't survive the transition via a real
> Open Firmware interface. There is no practical way to indicate reserved
> regions of memory accross in that case, unless you have an OS that is
> nice enough to try to keep OF alive and accomodate its advertised
> "available" properties, but that's typically not the case of Linux on
> ppc.
>
> So I would like to propose that we add a new "better" way to convey
> reserved memory information, via properties in the tree.
>
> I originally though of having these in the "memory" nodes themselves but
> this can be tricky on machines that have multiple nodes (ie, NUMA
> generally means a memory node per NUMA node) since the reserved regions
> can spawn accross nodes and I don't want to complicate FW life too much
> by requiring breaking them up in that case.
>
> So what about something at the root of the tree:
>
> reserved-ranges: An array of ranges of reserved memory
>
> reserved-names: A list of zero terminated strings, one for each entry in
> the reserved-ranges array, providing optional "names" for the reserved
> ranges.

I think this makes sense. Cyril and I are just talking about what he
needs. He wants to set aside per-device reserved regions and would
like to have the ability to reference a particular reserved region
from a device node, probably with a phandle. I like the look of the
reserved-{ranges,names} properties in the root, but I see the argument
that it isn't very flexible. What about something like this:

reserved-memory {
        reserved@0x10000000 { reg = <0x10000000 0x08000000>; };
        reserved@0x01000000 { reg = <0x01000000 0x00200000>; };
}

The node name of the child nodes could be different of course.

>
> The idea here is that we could have well defined names (using a similar
> prefix we use for properties) such as linux,initrd, which indicates
> clearly to the kernel that the only reason that range is reserved is
> because it contains an initrd (ie, it can be freed once that's been
> extracted).
>
> It would also be generally handy in case a reserved area is meant to be
> used by a specific driver, such as an in-memory framebuffer
> pre-initialized by the firmware. The generic memory management code
> doesn't need to know, but later on, the gfx driver can pick it up easily
> provided the name is part of the binding for that device.

Right, that would work also even though I prefer phandle references in
general. Is it conceivable that additional data would want to be
attached to a particular reserved region?

g.

Re: Deprecating reserve-map in favor of properties

[Benjamin Herrenschmidt]

On Thu, 2012-11-01 at 15:21 +0100, Grant Likely wrote:

> I think this makes sense. Cyril and I are just talking about what he
> needs. He wants to set aside per-device reserved regions and would
> like to have the ability to reference a particular reserved region
> from a device node, probably with a phandle. I like the look of the
> reserved-{ranges,names} properties in the root, but I see the argument
> that it isn't very flexible. What about something like this:
> 
> reserved-memory {
>         reserved@0x10000000 { reg = <0x10000000 0x08000000>; };
>         reserved@0x01000000 { reg = <0x01000000 0x00200000>; };
> }
> 
> The node name of the child nodes could be different of course.

I'm not that fan of different nodes, especially nodes with nodes in them
for that purpose. Seems overkill.

Can't he reference reserved entries as <phandle>,<index> pairs ?

I still think a single property would do fine. We could mandate those be
in the respective "memory" nodes but them you have potentially to break
up reserved regions if you have multiple memory nodes (NUMA) etc...

I'd vote for the simpler approach here...

> > The idea here is that we could have well defined names (using a similar
> > prefix we use for properties) such as linux,initrd, which indicates
> > clearly to the kernel that the only reason that range is reserved is
> > because it contains an initrd (ie, it can be freed once that's been
> > extracted).
> >
> > It would also be generally handy in case a reserved area is meant to be
> > used by a specific driver, such as an in-memory framebuffer
> > pre-initialized by the firmware. The generic memory management code
> > doesn't need to know, but later on, the gfx driver can pick it up easily
> > provided the name is part of the binding for that device.
> 
> Right, that would work also even though I prefer phandle references in
> general. Is it conceivable that additional data would want to be
> attached to a particular reserved region?

phandle references and names aren't exclusive from each other. The name
remains a useful diagnostic tool.

If you want additional data, make a node somewhere to represent that
region along with its additional data, that node can have a reference to
the reserved map entry.

I'd keep the reserve map itself simple. It's a "synthetic property" a
bit like the memory nodes. IE. The "memory" nodes don't have to
represent physical memory controllers & DIMMs. They represent the
overall view of memory by the CPUs. You can represent the MCs and the
DIMMs elsewhere in the SoC node.

Cheers,
Ben.

Re: Deprecating reserve-map in favor of properties

[Grant Likely]

On Fri, 02 Nov 2012 06:41:36 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2012-11-01 at 15:21 +0100, Grant Likely wrote:
> 
> > I think this makes sense. Cyril and I are just talking about what he
> > needs. He wants to set aside per-device reserved regions and would
> > like to have the ability to reference a particular reserved region
> > from a device node, probably with a phandle. I like the look of the
> > reserved-{ranges,names} properties in the root, but I see the argument
> > that it isn't very flexible. What about something like this:
> > 
> > reserved-memory {
> >         reserved@0x10000000 { reg = <0x10000000 0x08000000>; };
> >         reserved@0x01000000 { reg = <0x01000000 0x00200000>; };
> > }
> > 
> > The node name of the child nodes could be different of course.
> 
> I'm not that fan of different nodes, especially nodes with nodes in them
> for that purpose. Seems overkill.
> 
> Can't he reference reserved entries as <phandle>,<index> pairs ?

That would work too.

> I still think a single property would do fine. We could mandate those be
> in the respective "memory" nodes but them you have potentially to break
> up reserved regions if you have multiple memory nodes (NUMA) etc...

It makes sense to me for the reserved ranges to be kept with the memory
nodes themselves, even if it does mean that sometimes they need to be
split up for multiple memory nodes.

> > Right, that would work also even though I prefer phandle references in
> > general. Is it conceivable that additional data would want to be
> > attached to a particular reserved region?
> 
> phandle references and names aren't exclusive from each other. The name
> remains a useful diagnostic tool.
> 
> If you want additional data, make a node somewhere to represent that
> region along with its additional data, that node can have a reference to
> the reserved map entry.
> 
> I'd keep the reserve map itself simple. It's a "synthetic property" a
> bit like the memory nodes. IE. The "memory" nodes don't have to
> represent physical memory controllers & DIMMs. They represent the
> overall view of memory by the CPUs. You can represent the MCs and the
> DIMMs elsewhere in the SoC node.

okay.

g.