On 06/11/15 16:36, Marcel Apfelbaum wrote:
On 06/11/2015 05:24 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 05:12:33PM +0300, Marcel Apfelbaum wrote:
On 06/11/2015 04:58 PM, Kevin O'Connor wrote:
On Thu, Jun 11, 2015 at 04:37:08PM +0300, Marcel Apfelbaum wrote:
The fixes solves the following issue: The PXB device exposes a new pci root bridge with the fw path: /pci-root@4/..., in which 4 is the root bus number. Before this patch the fw path was wrongly computed: /pci-root@1/pci@i0cf8/... Fix the above issues: Correct the bus number and remove the extra host bridge description.
Why is that wrong? The previous path looks correct to me.
The prev path includes both the extra root bridge and *then* the usual host bridge. /pci-root@1/pci@i0cf8/ ... ^ new ^ regular ^ devices
Since the new pci root bridge (and bus) is on "paralel" with the regular one. it is not correct to add it to the path.
The architecture is: /<host bridge>/devices... /extra root bridge/devices... /extra root bridge/devices... And not /extra root bridge//<host bridge>/devices
Your patch changed both the "/extra root bridge/devices..." part and the "@1" part. The change of the "@1" in "/pci-root@1/" is not correct IMO.
Why? @1 should be the unit address which is the text representation of the physical address, in our case the slot. Since the bus number in our case is 4, I think /pci-root@4/ is the 'correct' address.
Does open-firmware have any examples for PCI paths and in particular PCI paths when there are multiple root-buses?
Maybe Laszlo can say more, but we both agreed that this would be the berst representation of extra root buses on both OVMF and Seabios.
The
PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware
document (binding) does speak about this, as far as I can see, in
2.2.1. Physical Address Formats
It first gives a "Numerical Representation" in device tree format (same thing as in DTB / FDT), and then a "Text Representation" with references to "Numerical Representation". It is *completely* Greek to me. It took me minutes of staring just to vaguely understand how the current
i0cf8
unit address comes together.
I've always treated the OFW devpaths that QEMU generates only *syntactically* conformant to the (base) OFW spec, and never considered the particular bindings 100% binding. That said, if someone finds where the PCI binding defines unit addresses for *root* buses, please let me know, just for reference.
It's possible to replace the "pci@i0cf8" with "pci-root@1" but that seems odd as the extra root bus is accessible via io accesses to 0x0cf8.
While this is true, /pci-root@[...]/ may represent also other kind of host bridges not only PXBs. But we can change this of course, as long as OVMF can also work with it.
Another option would be to place the pci-root@1 behind the pci@i0cf8 as in "/pci@i0cf8/pci-root@1/...". Or, the root bus could be appended to the host bridge as in "/pci@i0cf8,1/...".
The latest representation makes sense to me, but "/pci@i0cf8,4/...", after comma the bus number.
Laszlo, will this work for OVMF?
With the v3 patchset for QEMU, we could probably easily generate the "i0cf8,4" unit address inside the PXB device model itself. (Of course exactly what number should stand after the comma remains a question.)
Parsing it in OVMF is doable, albeit somewhat ugly.
In any case, I'm not convinced at all why this is a better idea than the proposal in this patch.
Laszlo