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

[Marcel Apfelbaum <marcel@redhat.com>]

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:
>>>
>>>         /pci@i0cf8/scsi@3/channel@0/disk@0,0
>>>         /pci/pci-bridge@0/ethernet@2/ethernet-phy@0
>>>
>>>       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 "/pci@i0cf8" 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. "/pci@i0cf8".)
>>>
>>>       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
>>>       "/pci-bridge@0" only gives away the slot number *on* the extra root
>>>       bus, not the number of the root bus itself.) For example:
>>>
>>>         /pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0
>>>
>>>       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
>
>    driver-name@unit-address: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:
>
>    /pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0
>         ^
>         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
>
>    /pci@4
>
> (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:
>
>    /pxb@4
>    /pci@4
Thanks a lot for the pointer. I prefer the latest.
I'll get to it.

Thanks,
Marcel

>
> Thanks
> Laszlo
>