Hi Peter,

I'm glad to hear these qemu general rules from you.
Here you raised two options:

  1.  Using a tool like libvirt to add a pluggable network card
  2.  Specify the network card on the command line

For the option2, I think specify the network model in command line is not 
enough, per my understanding, we still need to create the device using API like 
pci_create && qdev_set_nic_properties && qdev_init_nofail, otherwise we'll get 
error prompts like "requested NIC (anonymous, model virtio) was not created 
(not supported by this machine?)", currently I just add these pieces of code in 
/hw/mips/boston.c, Do you call these pieces of code board code and what's your 
suggestion?

You mentioned "optional pluggable cards should just be created without any 
board code required if the user specifies them on the command line."
I don't quite understand what you mean, if I don't want to use option1, how to 
create pluggable cards without any board code?

Best regards,
Tommy
________________________________
From: Peter Maydell <peter.mayd...@linaro.org>
Sent: Tuesday, April 2, 2019 10:37 AM
To: Tommy Jin
Cc: Aleksandar Markovic; qemu-devel@nongnu.org; pburton.wavecomp....@gmail.com
Subject: Re: [Qemu-devel] [PATCH] Adds virtio_net as the default netcard for 
mips boston board.

On Tue, 2 Apr 2019 at 09:29, Tommy Jin <t...@wavecomp.com> wrote:
> If always creating virtio-net-pci device is not a good idea, is it
> feasible to make virtio-net-pci as an option for boston without
> using libvirt?

It's always an option, just specify it on the command line.

> Actually, Botson board can have an Intel GBE network card in it,
> compared to mips malta, it also has a pcnet network card created
> in its machine, is it acceptable to create a pch_gbe network card
> if the user specify like "model=pch_gbe"?

Again, optional pluggable cards should just be created without
any board code required if the user specifies them on the command line.

In general, the QEMU command line does not aim for "short,
do what the user probably wants without them specifying
many options". It aims for "be flexible, allow the user
to configure what they want". The user-friendly interface
is supposed to be the next level up (libvirt, etc). This does
mean that command lines can get quite long in some cases. That's
unfortunate but I don't think we should be putting workarounds
for that in individual board models.

thanks
-- PMM
From 5ecb77ec9f6f1cfb02b23cdb9a1eb2eca905b12e Mon Sep 17 00:00:00 2001
From: tjin <t...@wavecomp.com>
Date: Tue, 2 Apr 2019 14:48:25 +0800
Subject: [PATCH] adds a virtio_net netcard for mips boston board

Adds a network card for boston to make it convenient for users who are verifying network related functionalities on this board.
As the linux kernel has already supported virtio_net, now add a virtio netcard for boston, to make virtio work properly, please:
1. set virtio net options in linux kernel, saying CONFIG_VIRTIO && CONFIG_VIRTIO_PCI && CONFIG_VIRTIO_NET
2. specify model=virtio when you start boston in qemu.

Signed-off-by: tjin <t...@wavecomp.com>
---
 hw/mips/boston.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/hw/mips/boston.c b/hw/mips/boston.c
index e5bab3c..97c1728 100644
--- a/hw/mips/boston.c
+++ b/hw/mips/boston.c
@@ -32,6 +32,7 @@
 #include "hw/mips/cps.h"
 #include "hw/mips/cpudevs.h"
 #include "hw/pci-host/xilinx-pcie.h"
+#include "hw/virtio/virtio-pci.h"
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "qemu/log.h"
@@ -422,6 +423,23 @@ xilinx_pcie_init(MemoryRegion *sys_mem, uint32_t bus_nr,
     return XILINX_PCIE_HOST(dev);
 }
 
+/* Plug network card  in pcie slot.*/
+static void network_init(PCIBus *bus)
+{
+    NICInfo *nd = &nd_table[0];
+    PCIDevice *eth;
+
+    /* Please set CONFIG_VIRTIO && CONFIG_VIRTIO_PCI && CONFIG_VIRTIO_NET */
+    /* of Linux kernel. */
+    if (nd->model && strcmp(nd->model, "virtio") == 0) {
+        eth = pci_create(bus,
+                        PCI_DEVFN(0, 1), "virtio-net-pci");
+
+        qdev_set_nic_properties(&eth->qdev, &nd_table[0]);
+        qdev_init_nofail(&eth->qdev);
+    }
+}
+
 static void boston_mach_init(MachineState *machine)
 {
     DeviceState *dev;
@@ -545,6 +563,9 @@ static void boston_mach_init(MachineState *machine)
         error_printf("Please provide either a -kernel or -bios argument\n");
         exit(1);
     }
+
+    /* Network card */
+    network_init(&PCI_BRIDGE(&pcie2->root)->sec_bus);
 }
 
 static void boston_mach_class_init(MachineClass *mc)
-- 
2.7.4

Reply via email to