Re: [Qemu-block] How to generate custom fw paths for IDE devices?

[Laszlo Ersek]

(updating Marcel's address to his GMail one)

On 07/18/18 23:13, Mark Cave-Ayland wrote:
> Hi all,
> 
> Following on from a couple of patches I've previously posted to the
> mailing list at
> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08836.html I've
> made some good progress with trying to add bootindex support to OpenBIOS
> but I'm stuck with generating the IDE device paths from QEMU.
> 
> According to OpenBIOS the device path for a cdrom on a sun4u machine
> should be:
> 
>   
> /address@hidden,0/address@hidden,1/address@hidden/address@hidden/address@hidden
> 
> whereas with my working patchset I'm currently generating:
> 
>   /address@hidden,0/address@hidden,1/address@hidden/address@hidden
> 
> The issue is that the address@hidden part is being generated by the IDE drive
> device attached to the IDE bus in hw/ide/qdev.c, and so I think I need
> to override idebus_get_fw_dev_path() to manually generate the remainder
> of the path including both the controller and the correctly named drive
> node.
> 
> One option may be to consider subclassing IDEBus and overriding
> idebus_get_fw_dev_path() there, but the cmd646 device is a child of
> TYPE_PCI_IDE which has its own internal IDEBus and so it seems
> overriding it is impossible.
> 
> Can anyone point me in the right direction as to how to generate the
> correct fw path for IDE devices in the above format for sun4u machines?

What prevents you from recognizing, in the guest firmware, the
OpenFirmware device path that is currently generated by QEMU?

I mean, the device path generated by QEMU looks technically correct; it
reflects how the IDE controller sits in a PCI B/D/F, and how the IDE
drive sits on an IDE controller. Or do you actually have an intermediate
IDE controller (at "address 0x8100" on the top IDE controller) in the
sun4u machine type? Is the address 0x8100 actually needed by the firmware?

If so, perhaps you could turn that intermediate IDE controller
("internal IDEBus") into its own class, and chain the instance of that
class like the rest of the bus controllers are chained. (Just
speculating...)

Thanks
Laszlo