diff mbox

[PULL,5/5] hw/arm/virt: Support legacy -nic command line syntax

Message ID 1452522868-25550-5-git-send-email-peter.maydell@linaro.org
State New
Headers show

Commit Message

Peter Maydell Jan. 11, 2016, 2:34 p.m. UTC 
From: Ashok Kumar <ashoks@broadcom.com>

Support the legacy -nic syntax for creating PCI network devices
as well as the new-style -device options. This makes life easier
for people moving from x86 KVM virtualization to ARM KVM virtualization
and expecting their network configuration options to work the same
way for both setups.

We use "virtio" as the default NIC model if the user doesn't specify one.

Signed-off-by: Ashok Kumar <ashoks@broadcom.com>
Message-id: 1452091659-17698-1-git-send-email-ashoks@broadcom.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: expanded and clarified commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 hw/arm/virt.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

Comments

Eric Auger Jan. 18, 2016, 1:29 p.m. UTC | #1 
Hi,

How is it supposed to live with Passthrough'ed NIC? Current way to
instantiate a VFIO platform NIC looks like:

-device vfio-amd-xgbe,host=e0900000.xgmac
where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
device and e0900000.xgmac is the name of the device in
/sys/bus/platform/devices.

Before that commit I was able to instantiate this VFIO device and got
networking working, testing it with ping. Now ping don't work anymore. I
Guess I now use this other default NIC?

Curiously it does not seem to prevent networking with upstreamed Calxeda
Midway device and I did not figure why yet?

Thank you in advance

Best Regards

Eric

On 01/11/2016 03:34 PM, Peter Maydell wrote:
> From: Ashok Kumar <ashoks@broadcom.com>
> 
> Support the legacy -nic syntax for creating PCI network devices
> as well as the new-style -device options. This makes life easier
> for people moving from x86 KVM virtualization to ARM KVM virtualization
> and expecting their network configuration options to work the same
> way for both setups.
> 
> We use "virtio" as the default NIC model if the user doesn't specify one.
> 
> Signed-off-by: Ashok Kumar <ashoks@broadcom.com>
> Message-id: 1452091659-17698-1-git-send-email-ashoks@broadcom.com
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> [PMM: expanded and clarified commit message]
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  hw/arm/virt.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index acc1fcb..fd52b76 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -808,6 +808,7 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
>      DeviceState *dev;
>      char *nodename;
>      int i;
> +    PCIHostState *pci;
>  
>      dev = qdev_create(NULL, TYPE_GPEX_HOST);
>      qdev_init_nofail(dev);
> @@ -847,6 +848,19 @@ static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
>          sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, pic[irq + i]);
>      }
>  
> +    pci = PCI_HOST_BRIDGE(dev);
> +    if (pci->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);
> +        }
> +    }
> +
>      nodename = g_strdup_printf("/pcie@%" PRIx64, base);
>      qemu_fdt_add_subnode(vbi->fdt, nodename);
>      qemu_fdt_setprop_string(vbi->fdt, nodename,
>
Peter Maydell Jan. 18, 2016, 1:34 p.m. UTC | #2 
On 18 January 2016 at 13:29, Eric Auger <eric.auger@linaro.org> wrote:
> How is it supposed to live with Passthrough'ed NIC? Current way to
> instantiate a VFIO platform NIC looks like:
>
> -device vfio-amd-xgbe,host=e0900000.xgmac
> where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
> device and e0900000.xgmac is the name of the device in
> /sys/bus/platform/devices.

> Before that commit I was able to instantiate this VFIO device and got
> networking working, testing it with ping. Now ping don't work anymore. I
> Guess I now use this other default NIC?
>
> Curiously it does not seem to prevent networking with upstreamed Calxeda
> Midway device and I did not figure why yet?

Hmm, I guess this is changing things in that we now will have a
virtio PCI device appearing if you use the default (-net nic -net user)
settings. But I don't see why that would particularly interfere
with VFIO passthrough, except in as much as the guest now has
two network cards in it and might be preferring one as eth0
rather than the other...

thanks
-- PMM
Eric Auger Jan. 18, 2016, 1:57 p.m. UTC | #3 
Hi Peter,
On 01/18/2016 02:34 PM, Peter Maydell wrote:
> On 18 January 2016 at 13:29, Eric Auger <eric.auger@linaro.org> wrote:
>> How is it supposed to live with Passthrough'ed NIC? Current way to
>> instantiate a VFIO platform NIC looks like:
>>
>> -device vfio-amd-xgbe,host=e0900000.xgmac
>> where vfio-amd-xgbe is the name of the VFIO AMD XGBE platform QEMU
>> device and e0900000.xgmac is the name of the device in
>> /sys/bus/platform/devices.
> 
>> Before that commit I was able to instantiate this VFIO device and got
>> networking working, testing it with ping. Now ping don't work anymore. I
>> Guess I now use this other default NIC?
>>
>> Curiously it does not seem to prevent networking with upstreamed Calxeda
>> Midway device and I did not figure why yet?
> 
> Hmm, I guess this is changing things in that we now will have a
> virtio PCI device appearing if you use the default (-net nic -net user)
> settings. But I don't see why that would particularly interfere
> with VFIO passthrough, except in as much as the guest now has
> two network cards in it and might be preferring one as eth0
> rather than the other...
Yes that's what currently happens I think. I get the slirp thing on eth0
and my passthrough'ed device on eth1. That's not very straightforward
for the end-user to get those 2 NIC's now. In case I passthrough some
NIC's I would have expected this default NIC not be instantiated?

Alex, how do you manage on x86 platforms with VFIO-PCI NIC?

Thanks

Eric
> 
> thanks
> -- PMM
>
Peter Maydell Jan. 18, 2016, 2:14 p.m. UTC | #4 
On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org> wrote:
> Hi Peter,
> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>> Hmm, I guess this is changing things in that we now will have a
>> virtio PCI device appearing if you use the default (-net nic -net user)
>> settings. But I don't see why that would particularly interfere
>> with VFIO passthrough, except in as much as the guest now has
>> two network cards in it and might be preferring one as eth0
>> rather than the other...
> Yes that's what currently happens I think. I get the slirp thing on eth0
> and my passthrough'ed device on eth1. That's not very straightforward
> for the end-user to get those 2 NIC's now. In case I passthrough some
> NIC's I would have expected this default NIC not be instantiated?

The QEMU networking layer only knows about networking controlled
by the -net or -netdev options (and in those cases it does disable
the default network device). Because the back-end for passthrough
NICs is completely unknown to QEMU (it is all done in hardware),
I'm not sure we have any way to know that the thing you've passed through
is a NIC and not some other random PCI device...

> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?

...but presumably the x86 folks have been here before us
and know how this should work :-)

thanks
-- PMM
Eric Auger Jan. 18, 2016, 2:54 p.m. UTC | #5 
On 01/18/2016 03:14 PM, Peter Maydell wrote:
> On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org> wrote:
>> Hi Peter,
>> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>>> Hmm, I guess this is changing things in that we now will have a
>>> virtio PCI device appearing if you use the default (-net nic -net user)
>>> settings. But I don't see why that would particularly interfere
>>> with VFIO passthrough, except in as much as the guest now has
>>> two network cards in it and might be preferring one as eth0
>>> rather than the other...
>> Yes that's what currently happens I think. I get the slirp thing on eth0
>> and my passthrough'ed device on eth1. That's not very straightforward
>> for the end-user to get those 2 NIC's now. In case I passthrough some
>> NIC's I would have expected this default NIC not be instantiated?
> 
> The QEMU networking layer only knows about networking controlled
> by the -net or -netdev options (and in those cases it does disable
> the default network device). Because the back-end for passthrough
> NICs is completely unknown to QEMU (it is all done in hardware),
> I'm not sure we have any way to know that the thing you've passed through
> is a NIC and not some other random PCI device...
> 
>> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
> 
> ...but presumably the x86 folks have been here before us
> and know how this should work :-)

Yes. maybe we could create a new network backend VFIO and use that kind
of cmd line:

NET_OPTIONS="-netdev VFIO,id=myeth0 \
-device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"

In the specialized VFIO-Platform device I can easily add a dummy NICConf
field and add

static Property amd_xgbe_properties[] = {
    DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
    DEFINE_PROP_END_OF_LIST(),
};

But it complexifies the user command line quite a lot and not sure it is
worth the candle?

Thanks

Eric


> 
> thanks
> -- PMM
>
Alex Williamson Jan. 18, 2016, 3:55 p.m. UTC | #6 
On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
> On 01/18/2016 03:14 PM, Peter Maydell wrote:
> > On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org>
> > wrote:
> > > Hi Peter,
> > > On 01/18/2016 02:34 PM, Peter Maydell wrote:
> > > > Hmm, I guess this is changing things in that we now will have a
> > > > virtio PCI device appearing if you use the default (-net nic
> > > > -net user)
> > > > settings. But I don't see why that would particularly interfere
> > > > with VFIO passthrough, except in as much as the guest now has
> > > > two network cards in it and might be preferring one as eth0
> > > > rather than the other...
> > > Yes that's what currently happens I think. I get the slirp thing
> > > on eth0
> > > and my passthrough'ed device on eth1. That's not very
> > > straightforward
> > > for the end-user to get those 2 NIC's now. In case I passthrough
> > > some
> > > NIC's I would have expected this default NIC not be instantiated?
> > 
> > The QEMU networking layer only knows about networking controlled
> > by the -net or -netdev options (and in those cases it does disable
> > the default network device). Because the back-end for passthrough
> > NICs is completely unknown to QEMU (it is all done in hardware),
> > I'm not sure we have any way to know that the thing you've passed
> > through
> > is a NIC and not some other random PCI device...
> > 
> > > Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
> > 
> > ...but presumably the x86 folks have been here before us
> > and know how this should work :-)

No, we haven't.  vfio-pci devices are opaque on x86, we don't know or
care that they're NICs or HBAs or GPUs or whatever.  If you don't want the default NIC, turn it off with -net none.  Don't want graphics, -nographics.  Default QEMU devices may be useful for the commandline, but do they really matter in practical use?

> Yes. maybe we could create a new network backend VFIO and use that kind
> of cmd line:
> 
> NET_OPTIONS="-netdev VFIO,id=myeth0 \
> -device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"
> 
> In the specialized VFIO-Platform device I can easily add a dummy NICConf
> field and add
> 
> static Property amd_xgbe_properties[] = {
>     DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
>     DEFINE_PROP_END_OF_LIST(),
> };
> 
> But it complexifies the user command line quite a lot and not sure it is
> worth the candle?

In the general case, I don't see vfio-pci going in this direction.  We
do not want to know this much about the device.  Thanks,

Alex
Eric Auger Jan. 18, 2016, 3:57 p.m. UTC | #7 
On 01/18/2016 04:55 PM, Alex Williamson wrote:
> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>>> On 18 January 2016 at 13:57, Eric Auger <eric.auger@linaro.org>
>>> wrote:
>>>> Hi Peter,
>>>> On 01/18/2016 02:34 PM, Peter Maydell wrote:
>>>>> Hmm, I guess this is changing things in that we now will have a
>>>>> virtio PCI device appearing if you use the default (-net nic
>>>>> -net user)
>>>>> settings. But I don't see why that would particularly interfere
>>>>> with VFIO passthrough, except in as much as the guest now has
>>>>> two network cards in it and might be preferring one as eth0
>>>>> rather than the other...
>>>> Yes that's what currently happens I think. I get the slirp thing
>>>> on eth0
>>>> and my passthrough'ed device on eth1. That's not very
>>>> straightforward
>>>> for the end-user to get those 2 NIC's now. In case I passthrough
>>>> some
>>>> NIC's I would have expected this default NIC not be instantiated?
>>>
>>> The QEMU networking layer only knows about networking controlled
>>> by the -net or -netdev options (and in those cases it does disable
>>> the default network device). Because the back-end for passthrough
>>> NICs is completely unknown to QEMU (it is all done in hardware),
>>> I'm not sure we have any way to know that the thing you've passed
>>> through
>>> is a NIC and not some other random PCI device...
>>>
>>>> Alex, how do you manage on x86 platforms with VFIO-PCI NIC?
>>>
>>> ...but presumably the x86 folks have been here before us
>>> and know how this should work :-)
> 
> No, we haven't.  vfio-pci devices are opaque on x86, we don't know or
> care that they're NICs or HBAs or GPUs or whatever.  If you don't want the default NIC, turn it off with -net none. 

Ah OK. That's perfect then ;-)

Thanks

Eric
 Don't want graphics, -nographics.  Default QEMU devices may be useful
for the commandline, but do they really matter in practical use?
> 
>> Yes. maybe we could create a new network backend VFIO and use that kind
>> of cmd line:
>>
>> NET_OPTIONS="-netdev VFIO,id=myeth0 \
>> -device vfio-amd-xgbe,host=e0900000.xgmac,netdev=myeth0"
>>
>> In the specialized VFIO-Platform device I can easily add a dummy NICConf
>> field and add
>>
>> static Property amd_xgbe_properties[] = {
>>     DEFINE_NIC_PROPERTIES(VFIOAmdXgbeDevice, conf),
>>     DEFINE_PROP_END_OF_LIST(),
>> };
>>
>> But it complexifies the user command line quite a lot and not sure it is
>> worth the candle?
> 
> In the general case, I don't see vfio-pci going in this direction.  We
> do not want to know this much about the device.  Thanks,
> 
> Alex
>
Peter Maydell Jan. 18, 2016, 4 p.m. UTC | #8 
On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.com> wrote:
> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>> > ...but presumably the x86 folks have been here before us
>> > and know how this should work :-)
>
> No, we haven't.  vfio-pci devices are opaque on x86, we don't
> know or care that they're NICs or HBAs or GPUs or whatever.
>  If you don't want the default NIC, turn it off with -net none.
>  Don't want graphics, -nographics.  Default QEMU devices may be
> useful for the commandline, but do they really matter in
> practical use?

"User is expected to use -net none" is a fine answer to "how
this should work"...

(I was thrown off track because http://wiki.qemu.org/Documentation/Networking
doesn't document '-net none', and also -net is the legacy
syntax -- is there a -netdev equivalent?)

thanks
-- PMM
Markus Armbruster Jan. 18, 2016, 4:29 p.m. UTC | #9 
Peter Maydell <peter.maydell@linaro.org> writes:

> On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.com> wrote:
>> On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
>>> On 01/18/2016 03:14 PM, Peter Maydell wrote:
>>> > ...but presumably the x86 folks have been here before us
>>> > and know how this should work :-)
>>
>> No, we haven't.  vfio-pci devices are opaque on x86, we don't
>> know or care that they're NICs or HBAs or GPUs or whatever.
>>  If you don't want the default NIC, turn it off with -net none.
>>  Don't want graphics, -nographics.  Default QEMU devices may be
>> useful for the commandline, but do they really matter in
>> practical use?
>
> "User is expected to use -net none" is a fine answer to "how
> this should work"...
>
> (I was thrown off track because http://wiki.qemu.org/Documentation/Networking
> doesn't document '-net none', and also -net is the legacy
> syntax -- is there a -netdev equivalent?)

-nodefaults ;-P
Alex Williamson Jan. 18, 2016, 4:32 p.m. UTC | #10 
On Mon, 2016-01-18 at 16:00 +0000, Peter Maydell wrote:
> On 18 January 2016 at 15:55, Alex Williamson <alex.williamson@redhat.
> com> wrote:
> > On Mon, 2016-01-18 at 15:54 +0100, Eric Auger wrote:
> > > On 01/18/2016 03:14 PM, Peter Maydell wrote:
> > > > ...but presumably the x86 folks have been here before us
> > > > and know how this should work :-)
> > 
> > No, we haven't.  vfio-pci devices are opaque on x86, we don't
> > know or care that they're NICs or HBAs or GPUs or whatever.
> >  If you don't want the default NIC, turn it off with -net none.
> >  Don't want graphics, -nographics.  Default QEMU devices may be
> > useful for the commandline, but do they really matter in
> > practical use?
> 
> "User is expected to use -net none" is a fine answer to "how
> this should work"...
> 
> (I was thrown off track because http://wiki.qemu.org/Documentation/Ne
> tworking
> doesn't document '-net none', and also -net is the legacy
> syntax -- is there a -netdev equivalent?)

My guess would be that -netdev is often used in conjunction with
-nodefaults and therefore it becomes unnecessary to explicitly disable
it.  Thanks,

Alex
diff mbox

Patch

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index acc1fcb..fd52b76 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -808,6 +808,7 @@  static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
     DeviceState *dev;
     char *nodename;
     int i;
+    PCIHostState *pci;
 
     dev = qdev_create(NULL, TYPE_GPEX_HOST);
     qdev_init_nofail(dev);
@@ -847,6 +848,19 @@  static void create_pcie(const VirtBoardInfo *vbi, qemu_irq *pic,
         sysbus_connect_irq(SYS_BUS_DEVICE(dev), i, pic[irq + i]);
     }
 
+    pci = PCI_HOST_BRIDGE(dev);
+    if (pci->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);
+        }
+    }
+
     nodename = g_strdup_printf("/pcie@%" PRIx64, base);
     qemu_fdt_add_subnode(vbi->fdt, nodename);
     qemu_fdt_setprop_string(vbi->fdt, nodename,