Re: [Qemu-devel] Re: [PATCHv8 00/16] boot order specification

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> > > Ah the problem is that we have not qdevified mac io bus. Since first to
> > > ide disks are automatically attached to mac-io bus device paths for them
> > > are incorrect. Next two ide devices will be attached to CMD646 and qemu
> > > will generate correct device paths for them:
> > >
> > > qemu-system-ppc -drive if=none,id=hda,file=/dev/null -device ide-drive,drive=hda,bootindex=1
> > > -drive if=none,id=cd,file=/dev/null -device ide-drive,drive=cd,bootindex=0 -nographic -drive
> > > if=none,id=hdb,file=/dev/null -device ide-drive,drive=hdb,bus=ide.0,bootindex=2 -drive
> > > if=none,id=hdc,file=/dev/null -device ide-drive,drive=hdc,bus=ide.0,bootindex=3
> > > adding '/grackle@fec00000/ide@3/drive@1/disk@1' at index 0
> > > adding '/grackle@fec00000/ide@3/drive@1/disk@0' at index 1
> > > adding '/grackle@fec00000/ide@3/drive@0/disk@0' at index 2
> > > adding '/grackle@fec00000/ide@3/drive@0/disk@1' at index 3
> > 
> > But why is the path almost the same as CMD646, shouldn't 'ide@3' be
> > different since the PCI device is not the same?
> >
> It should, but since the mac io is not qdevified there is no qdev pci
> device for it.

Note that a better long term solution for all these is to have qemu
maintain the device-tree, using libfdt, and pass it to the firmware.

I have a port of SLOF that I can't release just yet (soon hopefully) on
top of another ppc "machine" for qemu that will also hopefully be soon
out there, but basically, what I do there is pass the FDT to SLOF, in
which I use forth code to expand it into a real OF device-tree.

Then, my SLOF code "populates" methods for known devices.

The only problem with that approach is the phandles. OpenBIOS/SLOF/OFW
will "assign" it's own phandle to nodes it creates, ignoring the
"phandle" properties created by libfdt.

That means that linkage within the device-tree will be potentially
broken accross the transition (ie, interrupt-parent, interrupt-map
etc... all contain phandle values to reference another node).

The way I get away with it right now is that I never use such linkage in
SLOF and I preserve the original "phandle" properties, which Linux will
then pickup and use instead of the SLOF "native" phandle when parsing
the tree.

A better long run option would be to have OF itself (whichever variant)
use some remapping on the phandles (instead of making them just
pointers) so it can create nodes with specific phandles.

Once you have your device-tree in qemu, everything looks simpler, you no
longer have to play guess work as to what the path will look like inside
the firmware. It also opens the door for passing bits of the device-tree
dynamically to the kernel for hotplug etc...

Cheers,
Ben.