Re: [Qemu-devel] PXB fixes for QEMU, and extra root buses for OVMF

[Laszlo Ersek]

On 06/10/15 13:55, Marcel Apfelbaum wrote:
> On 06/10/2015 02:04 PM, Laszlo Ersek wrote:
>> On 06/10/15 11:09, Marcel Apfelbaum wrote:
>>> On 06/06/2015 02:45 AM, Laszlo Ersek wrote:
>>
>>>> (7) At least one issue remains to be solved (designed) in QEMU, for
>>>> both
>>>>       SeaBIOS's and OVMF's sake: booting off devices that are
>>>> located on
>>>>       the PXB. The problem is with the "bootorder" fw_cfg file.
>>>> Consider
>>>>       the following example:
>>>>
>>>>         /address@hidden/address@hidden/address@hidden/address@hidden,0
>>>>         /pci/address@hidden/address@hidden/address@hidden
>>>>
>>>>       which is generated for the options
>>>>
>>>>         -device virtio-scsi-pci,id=scsi0 \
>>>>         -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \
>>>>         \
>>>>         -device pxb,id=bridge1,bus_nr=4 \
>>>>         -device
>>>> e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=1
>>>>
>>>>       While the first entry is recognized by both SeaBIOS and OVMF, the
>>>>       second entry (generated for the NIC hanging off the PXB, see
>>>> above)
>>>>       is recognized by neither. (I tested OVMF, and investigated the
>>>>       SeaBIOS source, for this claim.)
>>>>
>>>>       For the SeaBIOS explanation, grep the source code for
>>>> FW_PCI_DOMAIN.
>>> Thanks for bringing it to my attention.
>>>
>>>>
>>>>       The OVMF explanation is that OVMF simply rejects the initial
>>>>       OpenFirmware device path node "/pci" with a controlled parse
>>>> error
>>>>       (as opposed to the "/address@hidden" node, which it recognizes and
>>>>       translates to UEFI in combination with the rest of that OFW
>>>> device
>>>>       path).
>>>>
>>>>       The "/pci" node comes from QEMU's sysbus_get_fw_dev_path()
>>>> function,
>>>>       file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) and
>>>>       (s->num_pio) branches apply. (The (s->num_pio) branch applies for
>>>>       the first entry, ie. "/address@hidden".)
>>>>
>>>>       Something has to be invented here to clue in both firmwares as to
>>>>       the root bus number (here bus_nr=4), in a format that is
>>>> compliant
>>>>       with the "OpenFirmware unit address" concept. (Note that
>>>>       "/address@hidden" only gives away the slot number *on* the extra
>>>> root
>>>>       bus, not the number of the root bus itself.) For example:
>>>>
>>>>         /address@hidden/address@hidden/address@hidden/address@hidden
>>>>
>>>>       would be acceptable. However, I don't know how to implement
>>>> this in
>>>>       sysbus_get_fw_dev_path().
>>> I'll look into it. What is the OpenFirmware unit address" concept ? :)
>>
>> Okay, I looked it up again (also rechecked the OVMF parser code) -- in
>> fact the example I gave would not be preferable.
>>
>> * Background:
>>
>> For the specification, please see "3.2.1.1 Node names" in
>>
>>    IEEE Standard for Boot (Initialization Configuration)
>>    Firmware: Core Requirements and Practices
>>
>> The notation is
>>
>>    address@hidden:device-arguments
>>
>> It says (excerpt):
>>
>>    The /driver name/ field is a sequence of between one and 31 letters,
>>    digits, and punctuation characters from the set “, . _ + - ”.
>>    Uppercase and lowercase characters are distinct. [...]
>>
>>    [...]
>>
>>    The /unit address/ field is the text representation of the physical
>>    address of the device within the address space defined by its parent
>>    node. The form of the text representation is bus-dependent.
>>
>> Please see the TranslatePciOfwNodes() function in OVMF, for the
>> "PCI-like" OFW device paths that OVMF currently recognizes -- just
>> scroll through the function to see the comments:
>>
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c#L582
>>
>>
>> * Therefore, the only kind of /unit address/ that OVMF has faced,
>> exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF
>> uses the helper function ParseUnitAddressHexList() to parse them. (It is
>> defined in the same file linked above.)
>>
>> It would be preferable to stick with this assumption. Therefore, let me
>> revise my earlier recommendation, and ask for:
>>
>>    /address@hidden/address@hidden/address@hidden/address@hidden
>>         ^
>>         bus_nr (hex, without 0x prefix)
>>
>> instead. Providing "pxb" as /driver name/ in the very first OFW node
>> would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize
>> the extra root bus. The single hex integer in the /unit address/ of the
>> first node would identify bus_nr. The rest of the nodes in the OFW
>> devpath are already recognized by OVMF.
>>
>> An alternative would be simply
>>
>>    /address@hidden
>>
>> (quoting just the first node), because I can still tell apart the
>> numeric ("4") /unit address/ from the "i0cf8" one that identifies the
>> main root bus.
>>
>> Summary: either of the following would be okay:
>>
>>    /address@hidden
>>    /address@hidden
> Thanks a lot for the pointer. I prefer the latest.

Indeed, the current initial node that is produced for the nonzero root
buses is "/pci", so the "only" part you need to append to them is
"@bus_nr". :)

Thanks!
Laszlo

> I'll get to it.
> 
> Thanks,
> Marcel
> 
>>
>> Thanks
>> Laszlo
>>
>