On Sat, 5 Apr 2025, at 11:09, BALATON Zoltan wrote:
> On Fri, 4 Apr 2025, Alexey Kardashevskiy wrote:
> > On Tue, 1 Apr 2025, at 01:26, BALATON Zoltan wrote:
> >> The FDT does not normally store name properties but reconstructs it
> >> from path but each node in Open Firmware should at least have this
> >> property. This is correctly handled in getprop but nextprop should
> >> also return it even if not present as a property. This patch fixes
> >> that and also skips phandle which does not appear in Open Firmware
> >> and only added for internal use by VOF.
> >>
> >> Explicit name properties are still allowed because they are needed
> >> e.g. on the root node that guests expect to have specific names as
> >> seen on real machines instead of being empty so sometimes the node
> >> name may need to be overriden.
> >>
> >> Signed-off-by: BALATON Zoltan <bala...@eik.bme.hu>
> >> ---
> >> I've tested this with pegasos2 but don't know how to test spapr.
> >> v2:
> >> Fixed a typo in commit message
> >> Simplified loop to get next property name
> >>
> >> hw/ppc/vof.c | 51 ++++++++++++++++++++++++++++++++++-----------------
> >> 1 file changed, 34 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/hw/ppc/vof.c b/hw/ppc/vof.c
> >> index 09cb77de93..790d67c096 100644
> >> --- a/hw/ppc/vof.c
> >> +++ b/hw/ppc/vof.c
> >> @@ -353,34 +353,51 @@ static uint32_t vof_nextprop(const void *fdt, 
> >> uint32_t phandle,
> >> {
> >>      int offset, nodeoff = fdt_node_offset_by_phandle(fdt, phandle);
> >>      char prev[OF_PROPNAME_LEN_MAX + 1];
> >> -    const char *tmp;
> >> +    const char *tmp = NULL;
> >> +    bool match = false;
> >>
> >>      if (readstr(prevaddr, prev, sizeof(prev))) {
> >>          return PROM_ERROR;
> >>      }
> >> -
> >> -    fdt_for_each_property_offset(offset, fdt, nodeoff) {
> >> -        if (!fdt_getprop_by_offset(fdt, offset, &tmp, NULL)) {
> >> -            return 0;
> >> +    /*
> >> +     * "name" may or may not be present in fdt but we should still return 
> >> it.
> >
> > yeah we should, at least, to match "getprop". I also wonder if VOF does 
> > not add "name", then what would do so, do we really expect to see such 
> > properties anywhere? Because if not, then we do not need to skip it as 
> > we won't find it.
> 
> I have to add it to fdt where needed. For example on pegasos MorphOS 
> checks the name of "/" and expects to find bplan,Pegasos2 which is how it 
> identifies the machine. So we need a specific name property there which is 
> one example when there will be explicit name property in the fdt. Maybe 
> it's needed on some other nodes sometimes but normally the default will be 
> sufficient but not always.

Put this paragraph to the commit log, this is useful.

> >> +     * Do that first and then skip it if seen later. Also skip phandle 
> >> which is
> >
> > (a nit) appears to me that if handling of a missing "name" was done 
> > after the last property, the patch would look simpler, but not sure and 
> > do not insist.
> 
> I put name first to match what OpenFirmware does which returns name first. 
> SLOF seems to do everything backwards (maybe a result of parsing the fdt 
> to build the device tree) and returns properties with inverted order so 
> name is last on SLOF but even then the order is matched by putting name 
> first when we return properties in the normal order otherwise it would not 
> be in same order when reversed. I don't know if it's significant, some 
> guests may expect to get a name first but most would probably look for the 
> name not its position. The order now matches OpenFirmware and pegasos2 
> SmartFirmware and SLOF backwards so I think name is now where it should be 
> so I'd leave it first. The loop may become simpler if we don't skip 
> phandle only name, the complexity is mostly from sometimes we need to skip 
> both in a row.
> 
> >> +     * an internal value we added in vof_build_dt but should not appear 
> >> here.
> >
> > I would not hide anything though, unless it breaks something. Thanks,
> 
> I did some tests with SLOF. This is what I get from SLOF:
> 
> package 0x1e64a890 /vdevice/v-scsi@71000003:
>          slof,from-fdt          0
>          reg                    71000003
>          device_type            "vscsi"
>          compatible             "IBM,v-scsi"
>          interrupts             [0x8 bytes, 2 cells]
>          [000] 00001103 00000000
>          ibm,#dma-address-cells 2
>          ibm,#dma-size-cells    2
>          ibm,my-dma-window      "q"
>          #address-cells         2
>          #size-cells            0
>          name                   "v-scsi"
> 
> This is VOF before patch:
> 
> package 0x00001122 /vdevice/v-scsi@71000003:
>          phandle                1122
>          #size-cells            0
>          #address-cells         2
>          ibm,my-dma-window      "q"
>          ibm,#dma-size-cells    2
>          ibm,#dma-address-cells 2
>          interrupts             [0x8 bytes, 2 cells]
>          [000] 00001103 00000000
>          compatible             "IBM,v-scsi"
>          device_type            "vscsi"
>          reg                    71000003
> 
> and this is VOF after patch:
> 
> package 0x00001122 /vdevice/v-scsi@71000003:
>          name                   "v-scsi"
>          #size-cells            0
>          #address-cells         2
>          ibm,my-dma-window      "q"
>          ibm,#dma-size-cells    2
>          ibm,#dma-address-cells 2
>          interrupts             [0x8 bytes, 2 cells]
>          [000] 00001103 00000000
>          compatible             "IBM,v-scsi"
>          device_type            "vscsi"
>          reg                    71000003
> 
> Apart from SLOF returning properties backwards this now matches better. 
> SLOF or other Open Firmware implementations don't return phandle property 
> because that's what you pass to nextprop or getprop to get the property in 
> the first place (listed next to package above) and it is returned by 
> finddevice so not normally stored as a property. But if Linux would add it 
> and it helps Linux to have it there already we can keep it, it did not 
> break OSes on pegasos as they only parse properties they need and ignore 
> the rest. So I can skip skipping phandle and add that back if it would be 
> better for Linux but didn't removing it fixed a warning about it too?
> 
> By the way, phandle is identifying the node so can't we use the fdt offset 

This is sort of what SLOF does - uses physical addresses of nodes.

> for it so we don't have to add phandle properties? Or does offset change 
> when editing the fdt?

afair it does.

> I think libfdt also uses offsets to identify nodes 
> so maybe these should be somewhat stable.

tl;dr: no, we want properties.

Stable phandles (vs fdt offset or address) was one of the main triggers to 
write this VOF in the first place as we already have a few predefined phandles 
in pseries - interrupt controller and something else, my memory is weak. They 
go to SLOF which then tells the QEMU what the actual phandle is [1].

When a PCI host bridge is plugged into a pseries VM - there is no SLOF at this 
point but there an fdt node with a reference to the XICS phandle. And this 
ibm,client-architecture-support thing (which can enforce reduced number of 
threads-per-core and things like that) which causes rebuilding of the tree 
which involves QEMU creating a diff, feeding it back to SLOF which then would 
update its internal tree (which happens when SLOF is juuust about do die and it 
is not not really functional any more) to then build FDT (and do [1], again) - 
and this requires matching phandles in the nodes. 

> 
> Regards,
> BALATON Zoltan
> 

Reply via email to