> > > 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
