Re: [Qemu-devel] Hang using PXB w/ DMI-PCI w/ PCI bridge

[Laszlo Ersek]

On 10/04/16 16:57, Daniel P. Berrange wrote:
> With the following command line, the guest will hang, with
> no output displayed at all - not even the BIOS displays:
> 
> qemu-system-x86_64 \
> -machine accel=kvm \
> -name guest=f23x86_64,debug-threads=on \
> -machine pc-q35-2.6,accel=kvm,usb=off,vmport=off \
> -m 8000 \
> -smp 8,sockets=8,cores=1,threads=1 \
> -numa node,nodeid=0,cpus=0-3,mem=4000 \
> -numa node,nodeid=1,cpus=4-5,mem=2000 \
> -numa node,nodeid=2,cpus=6-7,mem=2000 \
> -uuid ac4c9e05-6137-4bde-a33a-5c3623f44fb2 \
> -no-user-config \
> -nodefaults \
> -device sga \
> -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e \
> -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 \
> -device pxb-pcie,bus_nr=214,id=pci.3,numa_node=0,bus=pcie.0,addr=0x2 \
> -device pxb-pcie,bus_nr=234,id=pci.4,numa_node=1,bus=pcie.0,addr=0x3 \
> -device pxb-pcie,bus_nr=254,id=pci.5,numa_node=2,bus=pcie.0,addr=0x4 \
> -device i82801b11-bridge,id=pci.6,bus=pci.3,addr=0x0 \
> -device i82801b11-bridge,id=pci.7,bus=pci.4,addr=0x0 \
> -device i82801b11-bridge,id=pci.8,bus=pci.5,addr=0x0 \
> -device pci-bridge,chassis_nr=9,id=pci.9,bus=pci.6,addr=0x0 \
> -device pci-bridge,chassis_nr=10,id=pci.10,bus=pci.7,addr=0x0 \
> -device pci-bridge,chassis_nr=11,id=pci.11,bus=pci.8,addr=0x0 \
> -netdev user,id=hostnet0 \
> -device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:9f:58:3c,bus=pci.2,addr=0x1
>  \
> -chardev stdio,id=charserial0 \
> -device isa-serial,chardev=charserial0,id=serial0 \
> -display none
> 
> Removing both the 3rd and 4th pci-bridge devices (id=pci.10 & pci.11)
> fixes it.
> 
> I'm unclear if this is a mistake in my configuration, or a bug
> in QEMU or a bug in SeaBIOS ?

The standard question is "can you please capture the SeaBIOS debug
output, with

  -debugcon file:debug.log -global isa-debugcon.iobase=0x402

", however, I think I can see the error here, on the QEMU command line.

For pxb and pxb-pcie devices, the bus_nr property specifies the
hard-coded bus number of the extra root bridge in question. For all
non-root bridges directly or recursively behind said extra root bridge,
firmwares tend to assign bus numbers that succeed the bus_nr property of
the root bridge. Additionally, our bus number space is 0..255,
inclusive. This translates to:

- bus_nr=254 for pci.5 (hardcoded by QEMU),
- bus number 255 (assigned by the firmware) for pci.8,
- no remaining bus number (for the firmware to assign) for pci.11

I think if you decrease each of those bus_nr properties by 10 or 20 for
example, that should make it work.

In general the bus_nr properties of pxb / pxb-pcie devices partition the
0..255 bus number space, and hierarchies behind those extra root buses
have to fit in the bus number partitions. A bit more formally, for the
devices

  -device pxb-pcie,bus_nr=N,id=ID1,... \
  -device pxb-pcie,bus_nr=M,id=ID2,... \

where N<M, and there is no pxb[-pcie] device with bus_nr=Q such that
N<Q<M, the bridge hierarchy behind ID1 has to fit in the bus number
range [N+1,M-1] inclusive. Which translates to: you can't have more than
M-N-1 bridges behind ID1.

Thanks
Laszlo