Hi,
> From what I have been able to see, "pci->parent" is always NULL from
> the very beginning, so the IRQ is computed based only on the "pin" and
> the device number ("pci_bdf_to_dev(pci->bdf)"), and by that I mean
> the *original* pci->bdf, not the result of walking up the parent link.
On a typical guest yes.
You can add a pci bridge to qemu (-device pci-bridge,id=br), then hook
up one or more devices (-device virtio-scsi-pci,bus=br), and you can
watch bridge support in action ;)
> I don't know how I could bring a bus number into the mix (I just
> assume the bus number is 0 and stop after the first device path node,
> which happens to match the SeaBIOS (pci->parent == NULL) case.
The bus numbers are assigned by the firmware, i.e. seabios/ovmf. root
bus is 0, then seabios simply assigns increasing numbers starting with 1
for every secondary bus it finds. The bus number is written into the
pci config space of the bridge device.
> but I still
> don't know how I would figure out the bus number of the original
> device for which I'm trying to compute the IRQ line (for the
> PCI_LIB_ADDRESS write to PCI_INT_LINE_OFFSET).
Lookup parent (bridge) device. Then either read it from pci config
space, or check whenever ovmf has this cached somewhere anyway. There
is a PCI_BRIDGE_CONTROL_REGISTER struct, featuring a SecondaryBus field.
cheers,
Gerd
------------------------------------------------------------------------------
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
