[Skiboot] [RFC PATCH v2 2/8] Add ultravisor support in OPAL

[Michael Ellerman]

Ryan Grimm <grimm at linux.vnet.ibm.com> writes:
> Oliver, Michael, 
>
> Questions about implementation below and generally how to search for
> devices in the device tree.  I've found myself and other team members
> confused about how to do so.
>
> On Thu, 2019-11-21 at 15:26 +1100, Oliver O'Halloran wrote:
> *snip*
>> > 
>> > How about we have something like this in the doc, and use
>> > device_type
>> > "secure_memory" so we don't have the kernel try to use it as
>> > regular
>> > memory:
>> > 
>> > Skiboot parses secure memory from the HDAT tables and creates the
>> > secure-memory device tree node, similar to a memory@ node except
>> > the
>> > device_type is "secure_memory". For example:
>> > 
>> > .. code-block:: dts
>> > 
>> >         secure-memory at 100fe00000000 {
>> >                 device_type = "secure_memory";
>> >                 ibm,chip-id = <0>;
>> >                 reg = < 0x100fe 0x0 0x2 0x0>;
>> >         }
>> > 
>> > Regions of secure memory will be reserved by hostboot such as OCC,
>> > HOMER, and SBE.  Skiboot will use the existing reserve
>> > infrastructure
>> > to reserve them.
>> > For example:
>> > 
>> > .. code-block::
>> > 
>> >         ibm,HCODE at 100fffcaf0000
>> >         ibm,OCC at 100fffcdd0000
>> >         ibm,RINGOVD at 100fffcae0000
>> >         ibm,WOFDATA at 100fffcb90000
>> >         ibm,arch-reg-data at 100fffd700000
>> >         ibm,hbrt-code-image at 100fffcec0000
>> >         ibm,hbrt-data at 100fffd420000
>> >         ibm,homer-image at 100fffd800000
>> >         ibm,homer-image at 100fffdc00000
>> >         ibm,occ-common-area at 100ffff800000
>> >         ibm,sbe-comm at 100fffce90000
>> >         ibm,sbe-comm at 100fffceb0000
>> >         ibm,sbe-ffdc at 100fffce80000
>> >         ibm,sbe-ffdc at 100fffcea0000
>> >         ibm,secure-crypt-algo-code at 100fffce70000
>> >         ibm,uvbwlist at 100fffcad0000
>> > 
>> > For Mambo, ultra.tcl creates the secure-memory device tree node and
>> > is
>> > currently defined at 8GB with size 8GB.  Mambo has no protection on
>> > securememory, so a watchpoint could be used to ensure Skiboot does
>> > not
>> > touch secure memory.
>> > 
>> > For BML, the BML script parses secure memory from the Cronus config
>> > file and creates the secure-memory device tree node.
>> 
>> Looks ok to me. mpe might have some comments.
>
> How should Skiboot search for secure-memory in the device
> tree?   Should we be looking at device_type the way the kernel does
> with of_find_node_by_type?

Probably not.

device_type is like the "type" or "class" in the object oriented sense,
it is meant to describe what methods you can invoke on the node.

If you look at IEEE 1275 it says:

  “device_type”
  Standard property name to specify the implemented interface.
  ...
  Specifies the “device type” of this package, thus implying a specific
  set of package class methods implemented by this package.


So for a new binding we're writing today, which will only ever be used
with a FDT and not a real OF, it probably doesn't make much sense to use
device_type.

> Skiboot searches for some device nodes by compatible, and this is
> stated in https://elinux.org/Device_Tree_Usage :
>
> "Every node in the tree that represents a device is required to have 
> the compatible property. compatible is the key an operating system uses
> to decidewhich device driver to bind to a device."

In general the docs on elinux.org are quite FDT focused, so they are not
always correct when looking at Power because we still run on systems
that have actual OF, or our device trees evolved from systems that had
real OF.

However in this case that advice is definitely correct, all devices
should have a compatible property.

> I looked at memory@ of a running system and it has no compatible
> property, so is memory not considered a device like a cpu, bus, or
> ethernet adapter?

The quote above is talking about "which device driver to bind", but
historically there is no device driver for memory, it's just memory.

These days that's not quite so true, with persistent memory and device
memory and so on.

But the memory at x nodes come from a time when memory was wired pretty
straight into the CPU, so there was no need for a compatible or
anything fancy.

> When is it correct to search by name or by path?

For anything newly designed, where we control what is created in the
tree, we should not need to search by name or path. Searching by
compatible is always superior.

In practice we have systems that have badly designed device trees that
we can't fix, so we have to search by name or path.

Searching by name is OK, but compatible is superior because a node can
have multiple compatible values, but it can only have one name.

Searching by path sucks because it makes the structure of the tree API
which can then never be changed.

cheers