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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 19/07/18 09:29, Laszlo Ersek wrote:

> (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:
>>
>>    /pci@1fe,0/pci@1,1/ide@3/ide1@8100/cdrom@0
>>
>> whereas with my working patchset I'm currently generating:
>>
>>    /pci@1fe,0/pci@1,1/ide@3/drive@1
>>
>> The issue is that the drive@1 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?

In a word: compatibility. With the older SPARC/PPC machines the OSs are 
*very* picky about device names and often make assumptions about the DT 
layout instead of parsing it properly, simply because at that time 
no-one really thought of running the software on anything but a real 
machine.

> 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...)

In the case of the IDE device, the devices represent the 
primary/secondary interfaces and not the separate controllers: the 
primary lives at 0x8000 and the secondary at 0x8100.

The other problem with changing this is that currently as there is no 
bootindex support, these map to the legacy -hda and -cdrom options 
correctly so even if I could do this, and even if all the OSs would 
still parse the device path, it would have to be a complete cutover 
which would likely involve me being on the receiving end of some angry 
emails.

For PPC I've been playing with the macio device because MacOS refused to 
boot unless the nodes are named "ata-3" and "ata-4". So far I've only 
been able to do this by implementing a "dummy" macio Bus, reworking and 
attaching the macio-ide device to it, implementing minial Bus support, 
and then overriding the fw path function to rewrite the device name 
based upon its QOM type. That's a whole lot of work just to rename a 
device from "ide" to "ata-3" in the DT.

If you take a look at the function Thomas mentioned in his email 
(https://git.qemu.org/?p=qemu.git;a=blob;f=hw/ppc/spapr.c;h=421b2dd09b515502cd11ccdd26420a8117f80cda;hb=e1ea55668ffe6ce558a063f3a9621b761738e1f2#l2866) 
suddenly it makes sense why I had to suggest patches for naming PCI 
devices: the SLOF/SPAPR authors decided to replace the entire 
FwPathProvider so then all that is necessary is to rewrite the paths for 
the relevant devices in one place; this also nicely handles the 
difference between IDE vs. SCSI vs. USB vs. virtio DT nodes.

I certainly think it's worth keeping the PCI/sysbus patches I submitted 
to simplify the required logic, however it's clear to me that the above 
solution from SPAPR is going to be the best way forward for PPC and 
SPARC. Presumably this also explains why the patches didn't exist in the 
first place because the SLOF/SPAPR folks ignored the existing 
infrastructure and went ahead and did their own thing.

 From a design perspective I can completely understand why someone would 
come up with a design with a 1:1 correspondence between qdev and fw 
paths, but in reality it's the details that mean this just doesn't quite 
work in real life. In particular ISTM it's a big red flag that both 
IEEE-1275-based BIOSes, OpenBIOS and SLOF (upon which the design is 
heavily influenced) have to ignore the infrastructure based upon qdev 
and provide their own implementations.

Are there any other similar issues around other BIOSes, e.g. s390, 
SeaBIOS at all?


ATB,

Mark.