Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
---
default-configs/riscv32-softmmu.mak | 1 +
default-configs/riscv64-softmmu.mak | 1 +
hw/riscv/virt.c | 16 +++++++++++++++-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/default-configs/riscv32-softmmu.mak b/default-configs/riscv32-softmmu.mak
index 05fae82f1b..bb3dd34606 100644
--- a/default-configs/riscv32-softmmu.mak
+++ b/default-configs/riscv32-softmmu.mak
@@ -9,6 +9,7 @@ CONFIG_CADENCE=y
CONFIG_PCI_GENERIC=y
CONFIG_PCI_XILINX=y
+CONFIG_VIRTIO_PCI=y
CONFIG_VGA=y
CONFIG_VGA_PCI=y
diff --git a/default-configs/riscv64-softmmu.mak b/default-configs/riscv64-softmmu.mak
index 05fae82f1b..bb3dd34606 100644
--- a/default-configs/riscv64-softmmu.mak
+++ b/default-configs/riscv64-softmmu.mak
@@ -9,6 +9,7 @@ CONFIG_CADENCE=y
CONFIG_PCI_GENERIC=y
CONFIG_PCI_XILINX=y
+CONFIG_VIRTIO_PCI=y
CONFIG_VGA=y
CONFIG_VGA_PCI=y
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index e7f0716fb6..de6924e1c7 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -36,6 +36,7 @@
#include "hw/riscv/sifive_test.h"
#include "hw/riscv/virt.h"
#include "chardev/char.h"
+#include "net/net.h"
#include "sysemu/arch_init.h"
#include "sysemu/device_tree.h"
#include "exec/address-spaces.h"
@@ -392,6 +393,8 @@ static void riscv_virt_board_init(MachineState *machine)
MemoryRegion *system_memory = get_system_memory();
MemoryRegion *main_mem = g_new(MemoryRegion, 1);
MemoryRegion *mask_rom = g_new(MemoryRegion, 1);
+ DeviceState *dev;
+ PCIBus *pci_bus;
char *plic_hart_config;
size_t plic_hart_config_len;
int i;
@@ -506,13 +509,24 @@ static void riscv_virt_board_init(MachineState *machine)
qdev_get_gpio_in(DEVICE(s->plic), VIRTIO_IRQ + i));
}
- gpex_pcie_init(system_memory,
+ dev = gpex_pcie_init(system_memory,
memmap[VIRT_PCIE_ECAM].base,
memmap[VIRT_PCIE_ECAM].size,
memmap[VIRT_PCIE_MMIO].base,
memmap[VIRT_PCIE_MMIO].size,
memmap[VIRT_PCIE_PIO].base,
DEVICE(s->plic), true);
+ pci_bus = PCI_HOST_BRIDGE(dev)->bus;
+
+ for (i = 0; i < nb_nics; i++) {
+ NICInfo *nd = &nd_table[i];
+
+ if (!nd->model) {
+ nd->model = g_strdup("virtio");
+ }
+
+ pci_nic_init_nofail(nd, pci_bus, nd->model, NULL);
+ }
serial_mm_init(system_memory, memmap[VIRT_UART0].base,
0, qdev_get_gpio_in(DEVICE(s->plic), UART0_IRQ), 399193,
--
2.19.1
On 2018-11-21 10:03 a.m., Alistair Francis wrote:
> + pci_bus = PCI_HOST_BRIDGE(dev)->bus;
> +
> + for (i = 0; i < nb_nics; i++) {
> + NICInfo *nd = &nd_table[i];
> +
> + if (!nd->model) {
> + nd->model = g_strdup("virtio");
> + }
> +
> + pci_nic_init_nofail(nd, pci_bus, nd->model, NULL);
> + }
I don't understand what this patch actually accomplishes. It doesn't
seem to affect my network devices when running QEMU. Can you provide a
commit message explaining this?
Thanks,
Logan
On Wed, Nov 21, 2018 at 10:07 AM Logan Gunthorpe <logang@deltatee.com> wrote:
>
>
> On 2018-11-21 10:03 a.m., Alistair Francis wrote:
> > + pci_bus = PCI_HOST_BRIDGE(dev)->bus;
> > +
> > + for (i = 0; i < nb_nics; i++) {
> > + NICInfo *nd = &nd_table[i];
> > +
> > + if (!nd->model) {
> > + nd->model = g_strdup("virtio");
> > + }
> > +
> > + pci_nic_init_nofail(nd, pci_bus, nd->model, NULL);
> > + }
>
> I don't understand what this patch actually accomplishes. It doesn't
> seem to affect my network devices when running QEMU. Can you provide a
> commit message explaining this?
Could you connect a PCIe networking device without this commit? This
is what the other architectures all do as well.
I'll rejig the commit message/title to make this clearer.
Alistair
>
> Thanks,
>
> Logan
On 2018-11-21 11:34 a.m., Alistair Francis wrote: >> I don't understand what this patch actually accomplishes. It doesn't >> seem to affect my network devices when running QEMU. Can you provide a >> commit message explaining this? > > Could you connect a PCIe networking device without this commit? This > is what the other architectures all do as well. Yes, actually. Other architectures doing something is never a sufficient justification to make a change. I'm also not sure how virtio relates to this patch... I'd say unless you know you're fixing something specific and can describe it, you should drop this patch. Logan
On Wed, Nov 21, 2018 at 11:12 AM Logan Gunthorpe <logang@deltatee.com> wrote: > > > > On 2018-11-21 11:34 a.m., Alistair Francis wrote: > >> I don't understand what this patch actually accomplishes. It doesn't > >> seem to affect my network devices when running QEMU. Can you provide a > >> commit message explaining this? > > > > Could you connect a PCIe networking device without this commit? This > > is what the other architectures all do as well. > > Yes, actually. > > Other architectures doing something is never a sufficient justification > to make a change. I'm also not sure how virtio relates to this patch... > > I'd say unless you know you're fixing something specific and can > describe it, you should drop this patch. It is required for networking for PCIe devices. What PCIe device works for you without this patch? Can you tell me your command line arguments. Alistair > > Logan
On 2018-11-21 2:55 p.m., Alistair Francis wrote:
> It is required for networking for PCIe devices. What PCIe device works
> for you without this patch? Can you tell me your command line
> arguments.
I can run it without that patch using a e1000e device and it works just
fine.
Command line:
$QEMU -s -nographic -machine virt -m 2G -kernel $BBL \
-object rng-random,filename=/dev/urandom,id=rng0 \
-append "console=hvc0 ro root=/dev/vda" \
-device e1000e,netdev=net0 \
-netdev user,id=net0 \
-device virtio-rng-device,rng=rng0 \
-device virtio-blk-device,drive=hd0 \
-drive file=rootfs.img,format=raw,id=hd0 \
-device nvme,drive=nvme0,serial=nvme0 \
-drive file=nvme0.qcow2,if=none,id=nvme0
--
lspcirv-hfu-01:~#
00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge
00:01.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
00:02.0 Non-Volatile memory controller: Intel Corporation QEMU NVM
Express Controller (rev 02)
root@rv-hfu-01:~#
QEMU 3.0.92 monitor - type 'help' for more information
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device 1b36:0008
PCI subsystem 1af4:1100
id ""
Bus 0, device 1, function 0:
Ethernet controller: PCI device 8086:10d3
PCI subsystem 8086:0000
IRQ 11.
BAR0: 32 bit memory at 0x40040000 [0x4005ffff].
BAR1: 32 bit memory at 0x40060000 [0x4007ffff].
BAR2: I/O at 0xffffffffffffffff [0x001e].
BAR3: 32 bit memory at 0x40080000 [0x40083fff].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
id ""
Bus 0, device 2, function 0:
Class 0264: PCI device 8086:5845
PCI subsystem 1af4:1100
IRQ 9.
BAR0: 64 bit memory at 0x40084000 [0x40085fff].
id ""
(qemu)
On Wed, Nov 21, 2018 at 2:07 PM Logan Gunthorpe <logang@deltatee.com> wrote: > > > > On 2018-11-21 2:55 p.m., Alistair Francis wrote: > > It is required for networking for PCIe devices. What PCIe device works > > for you without this patch? Can you tell me your command line > > arguments. > > I can run it without that patch using a e1000e device and it works just > fine. > > Command line: > > $QEMU -s -nographic -machine virt -m 2G -kernel $BBL \ > -object rng-random,filename=/dev/urandom,id=rng0 \ > -append "console=hvc0 ro root=/dev/vda" \ > -device e1000e,netdev=net0 \ > -netdev user,id=net0 \ > -device virtio-rng-device,rng=rng0 \ > -device virtio-blk-device,drive=hd0 \ > -drive file=rootfs.img,format=raw,id=hd0 \ > -device nvme,drive=nvme0,serial=nvme0 \ > -drive file=nvme0.qcow2,if=none,id=nvme0 > > -- > > lspcirv-hfu-01:~# > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > 00:01.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 00:02.0 Non-Volatile memory controller: Intel Corporation QEMU NVM > Express Controller (rev 02) > root@rv-hfu-01:~# > > QEMU 3.0.92 monitor - type 'help' for more information > (qemu) info pci > Bus 0, device 0, function 0: > Host bridge: PCI device 1b36:0008 > PCI subsystem 1af4:1100 > id "" > Bus 0, device 1, function 0: > Ethernet controller: PCI device 8086:10d3 > PCI subsystem 8086:0000 > IRQ 11. > BAR0: 32 bit memory at 0x40040000 [0x4005ffff]. > BAR1: 32 bit memory at 0x40060000 [0x4007ffff]. > BAR2: I/O at 0xffffffffffffffff [0x001e]. > BAR3: 32 bit memory at 0x40080000 [0x40083fff]. > BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. > id "" > Bus 0, device 2, function 0: > Class 0264: PCI device 8086:5845 > PCI subsystem 1af4:1100 > IRQ 9. > BAR0: 64 bit memory at 0x40084000 [0x40085fff]. > id "" > (qemu) and networking works? Alistair
On Wed, Nov 21, 2018 at 2:11 PM Alistair Francis <alistair23@gmail.com> wrote: > > On Wed, Nov 21, 2018 at 2:07 PM Logan Gunthorpe <logang@deltatee.com> wrote: > > > > > > > > On 2018-11-21 2:55 p.m., Alistair Francis wrote: > > > It is required for networking for PCIe devices. What PCIe device works > > > for you without this patch? Can you tell me your command line > > > arguments. > > > > I can run it without that patch using a e1000e device and it works just > > fine. > > > > Command line: > > > > $QEMU -s -nographic -machine virt -m 2G -kernel $BBL \ > > -object rng-random,filename=/dev/urandom,id=rng0 \ > > -append "console=hvc0 ro root=/dev/vda" \ > > -device e1000e,netdev=net0 \ > > -netdev user,id=net0 \ > > -device virtio-rng-device,rng=rng0 \ > > -device virtio-blk-device,drive=hd0 \ > > -drive file=rootfs.img,format=raw,id=hd0 \ > > -device nvme,drive=nvme0,serial=nvme0 \ > > -drive file=nvme0.qcow2,if=none,id=nvme0 > > > > -- > > > > lspcirv-hfu-01:~# > > 00:00.0 Host bridge: Red Hat, Inc. QEMU PCIe Host bridge > > 00:01.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > 00:02.0 Non-Volatile memory controller: Intel Corporation QEMU NVM > > Express Controller (rev 02) > > root@rv-hfu-01:~# > > > > QEMU 3.0.92 monitor - type 'help' for more information > > (qemu) info pci > > Bus 0, device 0, function 0: > > Host bridge: PCI device 1b36:0008 > > PCI subsystem 1af4:1100 > > id "" > > Bus 0, device 1, function 0: > > Ethernet controller: PCI device 8086:10d3 > > PCI subsystem 8086:0000 > > IRQ 11. > > BAR0: 32 bit memory at 0x40040000 [0x4005ffff]. > > BAR1: 32 bit memory at 0x40060000 [0x4007ffff]. > > BAR2: I/O at 0xffffffffffffffff [0x001e]. > > BAR3: 32 bit memory at 0x40080000 [0x40083fff]. > > BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe]. > > id "" > > Bus 0, device 2, function 0: > > Class 0264: PCI device 8086:5845 > > PCI subsystem 1af4:1100 > > IRQ 9. > > BAR0: 64 bit memory at 0x40084000 [0x40085fff]. > > id "" > > (qemu) > > and networking works? Yep, it should. This is for the -nic option [1]. I misunderstood when I was going through it. We can drop this patch then. 1: https://github.com/qemu/qemu/commit/fea9b3ca9cc4685f89e0b929a61e51098fbb4f49 Alistair > > Alistair
On 2018-11-21 3:14 p.m., Alistair Francis wrote: >> and networking works? > > Yep, it should. This is for the -nic option [1]. I misunderstood when > I was going through it. > > We can drop this patch then. > > 1: https://github.com/qemu/qemu/commit/fea9b3ca9cc4685f89e0b929a61e51098fbb4f49 Ah, ok, that clears it up. You can drop it or keep it, but if you keep it you should have a similar commit message. Logan
On 2018-11-21 3:16 p.m., Logan Gunthorpe wrote: > > > On 2018-11-21 3:14 p.m., Alistair Francis wrote: >>> and networking works? >> >> Yep, it should. This is for the -nic option [1]. I misunderstood when >> I was going through it. >> >> We can drop this patch then. >> >> 1: https://github.com/qemu/qemu/commit/fea9b3ca9cc4685f89e0b929a61e51098fbb4f49 > > Ah, ok, that clears it up. You can drop it or keep it, but if you keep > it you should have a similar commit message. Though, if you choose to keep the patch, falling back to virtio as the default NIC may not be the correct choice seeing the machine does not have any virtio bus... Logan
© 2016 - 2025 Red Hat, Inc.