default-configs/riscv32-softmmu.mak | 10 ++- default-configs/riscv64-softmmu.mak | 10 ++- hw/riscv/sifive_u.c | 64 ++++++++++++++ hw/riscv/virt.c | 125 ++++++++++++++++++++++++++++ include/hw/riscv/sifive_u.h | 4 +- include/hw/riscv/virt.h | 8 +- 6 files changed, 216 insertions(+), 5 deletions(-)
V6: - Fix the interrupt issue for the GPEX device V5: - Rebase - Include pci.mak in the default configs V4: - Fix the spike device tree - Don't use stdvga device V3: - Remove Makefile config changes - Connect a network adapter to the virt device V2: - Use the gpex PCIe host for virt - Add support for SiFive U PCIe Alistair Francis (5): hw/riscv/virt: Increase the number of interrupts hw/riscv/virt: Connect the gpex PCIe riscv: Enable VGA and PCIE_VGA hw/riscv/sifive_u: Connect the Xilinx PCIe hw/riscv/virt: Connect a VirtIO net PCIe device default-configs/riscv32-softmmu.mak | 10 ++- default-configs/riscv64-softmmu.mak | 10 ++- hw/riscv/sifive_u.c | 64 ++++++++++++++ hw/riscv/virt.c | 125 ++++++++++++++++++++++++++++ include/hw/riscv/sifive_u.h | 4 +- include/hw/riscv/virt.h | 8 +- 6 files changed, 216 insertions(+), 5 deletions(-) -- 2.19.1
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. 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 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 :) -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Oct 31, 2018 at 7:51 AM Andrea Bolognani <abologna@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 >
On Wed, 2018-10-31 at 13:10 -0700, Alistair Francis wrote: > On Wed, Oct 31, 2018 at 7:51 AM Andrea Bolognani <abologna@redhat.com> wrote: > > 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. I see. Are there plans for that to change? Will we eventually need something like Arm's 'gic-version' machine option to pick a more featureful interrupt controller? Either way, as it is we certainly can't flip the default to virtio-pci at the libvirt level quite yet, so we'll have to stick with virtio-mmio for a while longer... Not exactly the outcome I was hoping for :( > > 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 :) Sorry, not really my area of expertise O:-) -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Nov 1, 2018 at 1:20 AM Andrea Bolognani <abologna@redhat.com> wrote: > > On Wed, 2018-10-31 at 13:10 -0700, Alistair Francis wrote: > > On Wed, Oct 31, 2018 at 7:51 AM Andrea Bolognani <abologna@redhat.com> wrote: > > > 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. > > I see. Are there plans for that to change? Will we eventually need > something like Arm's 'gic-version' machine option to pick a more > featureful interrupt controller? I don't think there is even MSI support in the interrupt spec (I haven't looked at all though), yet alone in QEMU. Unfortunately it seems low down on the list of things we need to do so it will probably be awhile. Alistair > > Either way, as it is we certainly can't flip the default to > virtio-pci at the libvirt level quite yet, so we'll have to stick > with virtio-mmio for a while longer... Not exactly the outcome I > was hoping for :( > > > > 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 :) > > Sorry, not really my area of expertise O:-) > > -- > Andrea Bolognani / Red Hat / Virtualization >
On Wed, 2018-11-07 at 13:47 -0800, Alistair Francis wrote: > I don't think there is even MSI support in the interrupt spec (I > haven't looked at all though), yet alone in QEMU. Unfortunately it > seems low down on the list of things we need to do so it will probably > be awhile. That's perfectly fine; just be aware of the fact that, until pcie-root-port can be used successfully, libvirt users will still get virtio-mmio by default for RISC-V guests and will have to jump through significant hoops in order to use virtio-pci instead. -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2025 Red Hat, Inc.