mbox series

[v6,0/5] Connect a PCIe host and graphics support to RISC-V

Message ID cover.1540937826.git.alistair.francis@wdc.com (mailing list archive)
Headers show
Series Connect a PCIe host and graphics support to RISC-V | expand

Message

Alistair Francis Oct. 30, 2018, 10:17 p.m. UTC
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(-)

Comments

Andrea Bolognani Oct. 31, 2018, 2:51 p.m. UTC | #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 :)
Alistair Francis Oct. 31, 2018, 8:10 p.m. UTC | #2
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
>
Andrea Bolognani Nov. 1, 2018, 8:20 a.m. UTC | #3
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:-)
Alistair Francis Nov. 7, 2018, 9:47 p.m. UTC | #4
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
>
Andrea Bolognani Nov. 13, 2018, 3:52 p.m. UTC | #5
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.