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

[Laszlo Ersek <lersek@redhat.com>]

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
Laszlo