On Wed, Oct 31, 2018 at 7:51 AM Andrea Bolognani <abolo...@redhat.com> wrote: > > On Tue, 2018-10-30 at 22:17 +0000, Alistair Francis wrote: > > V6: > > - Fix the interrupt issue for the GPEX device > > I gave this a spin. > > With the pcie.0 <- pcie-root-port <- virtio-net-pci setup I get > > qemu-system-riscv64: -device pcie-root-port,port=0x8,chassis=1,\ > id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: MSI-X is not \ > supported by interrupt controller > > just like last time, which as I mentioned is a problem for libvirt > because we follow the recommendations outlined in qemu/docs/pcie.txt > and never plug devices into pcie.0 directly.
At the moment we can't support MSI, the interrupt controller doesn't support MSI. > > Even after working around that issue by manually placing the device > at 0000:00:01.0, it still doesn't work: I see > > pci 0000:00:01.0: BAR 6: assigned [mem 0x00000000-0x0003ffff pref] > pci 0000:00:01.0: BAR 4: assigned [mem 0x00040000-0x00043fff 64bit pref] > pci 0000:00:01.0: BAR 0: no space for [io size 0x0020] > pci 0000:00:01.0: BAR 0: failed to assign [io size 0x0020] > ... > virtio_net virtio3: virtio: device uses modern interface but does not have > VIRTIO_F_VERSION_1 > virtio_net: probe of virtio3 failed with error -22 Yep, someone else pointed out a problem as well. I have made some changes [1] but I still can't get the BAR to line up. > > in dmesg and, while the device shows up in the output of lspci(8), > it's nowhere to be seen when running 'ip addr' and friends. > > Let me know if you need me to try anything else :) Any ideas on how to debug the confusing memory mappings or non-existent interrupts would be helpful :) 1: https://github.com/alistair23/qemu/tree/mainline/alistair/sifive_pcie.next Alistair > > -- > Andrea Bolognani / Red Hat / Virtualization >
