[Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Thomas Huth]

So far, it is not possible to use the network dump interface
with the "-netdev" option yet, it only works with the legacy
"-net" option. To be able to use it with "-netdev", too, this
patch now enables the "vlan" packet distribution for the
"-netdev" option, too, so that you can now dump network packets
like this:

qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
        -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
        -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 net/net.c        | 3 +++
 qapi-schema.json | 1 +
 2 files changed, 4 insertions(+)

 [Note: I'm quite new to this area of the code, please review carefully
  whether this approach makes sense or whether it should be done differently]

diff --git a/net/net.c b/net/net.c
index 7427f6a..3595910 100644
--- a/net/net.c
+++ b/net/net.c
@@ -872,6 +872,7 @@ static int net_client_init1(const void *object, int is_netdev, Error **errp)
 #ifdef CONFIG_L2TPV3
         case NET_CLIENT_OPTIONS_KIND_L2TPV3:
 #endif
+        case NET_CLIENT_OPTIONS_KIND_DUMP:
             break;
 
         default:
@@ -895,6 +896,8 @@ static int net_client_init1(const void *object, int is_netdev, Error **errp)
             (opts->kind != NET_CLIENT_OPTIONS_KIND_NIC ||
              !opts->nic->has_netdev)) {
             peer = net_hub_add_port(u.net->has_vlan ? u.net->vlan : 0, NULL);
+        } else if (is_netdev && u.netdev->has_vlan) {
+            peer = net_hub_add_port(u.netdev->vlan, NULL);
         }
 
         if (net_client_init_fun[opts->kind](opts, name, peer) < 0) {
diff --git a/qapi-schema.json b/qapi-schema.json
index f97ffa1..adb0722 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2512,6 +2512,7 @@
 { 'struct': 'Netdev',
   'data': {
     'id':   'str',
+    '*vlan': 'int32',
     'opts': 'NetClientOptions' } }
 
 ##
-- 
1.8.3.1

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On 05/22/2015 01:22 PM, Thomas Huth wrote:
> So far, it is not possible to use the network dump interface
> with the "-netdev" option yet, it only works with the legacy
> "-net" option. To be able to use it with "-netdev", too, this
> patch now enables the "vlan" packet distribution for the
> "-netdev" option, too, so that you can now dump network packets
> like this:
> 
> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---

> +++ b/qapi-schema.json
> @@ -2512,6 +2512,7 @@
>  { 'struct': 'Netdev',
>    'data': {
>      'id':   'str',
> +    '*vlan': 'int32',
>      'opts': 'NetClientOptions' } }

Needs a documentation blurb for the new parameter, including '#optional'
and '(since 2.4)' markings.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]

On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
> So far, it is not possible to use the network dump interface
> with the "-netdev" option yet, it only works with the legacy
> "-net" option. To be able to use it with "-netdev", too, this
> patch now enables the "vlan" packet distribution for the
> "-netdev" option, too, so that you can now dump network packets
> like this:
> 
> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  net/net.c        | 3 +++
>  qapi-schema.json | 1 +
>  2 files changed, 4 insertions(+)
> 
>  [Note: I'm quite new to this area of the code, please review carefully
>   whether this approach makes sense or whether it should be done differently]

We thought the QEMU "vlan" concept would be dropped completely in the
future, so it was never added to -netdev.  No patches to do that have
been posted over the years, so I think it was more of a conceptual goal
than a concrete requirement.

I'm okay with merging this but will leave some time for discussion
before merging the patch.

"Speak now or forever hold your peace"

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Thomas Huth]

On Tue, 26 May 2015 13:52:35 +0100
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
> > So far, it is not possible to use the network dump interface
> > with the "-netdev" option yet, it only works with the legacy
> > "-net" option. To be able to use it with "-netdev", too, this
> > patch now enables the "vlan" packet distribution for the
> > "-netdev" option, too, so that you can now dump network packets
> > like this:
> > 
> > qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
> >         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
> >         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  net/net.c        | 3 +++
> >  qapi-schema.json | 1 +
> >  2 files changed, 4 insertions(+)
> > 
> >  [Note: I'm quite new to this area of the code, please review carefully
> >   whether this approach makes sense or whether it should be done differently]
> 
> We thought the QEMU "vlan" concept would be dropped completely in the
> future, so it was never added to -netdev.  No patches to do that have
> been posted over the years, so I think it was more of a conceptual goal
> than a concrete requirement.
> 
> I'm okay with merging this but will leave some time for discussion
> before merging the patch.
> 
> "Speak now or forever hold your peace"

Certainly no objections from my side to keep this "vlan" concept in
QEMU, but thinking about this option again, I'd rather call it "hub=xx"
for the -netdev option instead of "vlan=xx", since this better matches
the "-netdev hubport" naming and it IMHO also describes the
functionality in a better way.
(of course I also need to add proper updates to the documentation files
in my patch in that way)

 Thomas

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Paolo Bonzini]

On 26/05/2015 15:07, Thomas Huth wrote:
> Certainly no objections from my side to keep this "vlan" concept in
> QEMU, but thinking about this option again, I'd rather call it "hub=xx"
> for the -netdev option instead of "vlan=xx", since this better matches
> the "-netdev hubport" naming and it IMHO also describes the
> functionality in a better way.
> (of course I also need to add proper updates to the documentation files
> in my patch in that way)

I agree.  It makes sense, because vlans have other uses besides dump
(e.g. connecting VMs via the socket or l2tpv3 backends, where VMs have
multiple NICs).

Paolo

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Markus Armbruster]

Stefan Hajnoczi <stefanha@redhat.com> writes:

> On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
>> So far, it is not possible to use the network dump interface
>> with the "-netdev" option yet, it only works with the legacy
>> "-net" option. To be able to use it with "-netdev", too, this
>> patch now enables the "vlan" packet distribution for the
>> "-netdev" option, too, so that you can now dump network packets
>> like this:
>> 
>> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
>>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
>>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
>> 
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>  net/net.c        | 3 +++
>>  qapi-schema.json | 1 +
>>  2 files changed, 4 insertions(+)
>> 
>>  [Note: I'm quite new to this area of the code, please review carefully
>>   whether this approach makes sense or whether it should be done differently]
>
> We thought the QEMU "vlan" concept would be dropped completely in the
> future, so it was never added to -netdev.  No patches to do that have
> been posted over the years, so I think it was more of a conceptual goal
> than a concrete requirement.

Well, patches to do that first need to replace the VLAN-only dump
feature.

To fully deprecate -net, we also have to replace -net nic for
configuring onboard NICs.

Prior discussion:
http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html

We haven't really tried either.

Thomas's patch declares defeat on VLANs: it ports them to -netdev,
perpetuating the concept.

> I'm okay with merging this but will leave some time for discussion
> before merging the patch.
>
> "Speak now or forever hold your peace"

Sure we're ready to give up without having tried?

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Daniel P. Berrange]

On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
> 
> > On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
> >> So far, it is not possible to use the network dump interface
> >> with the "-netdev" option yet, it only works with the legacy
> >> "-net" option. To be able to use it with "-netdev", too, this
> >> patch now enables the "vlan" packet distribution for the
> >> "-netdev" option, too, so that you can now dump network packets
> >> like this:
> >> 
> >> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
> >>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
> >>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
> >> 
> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >> ---
> >>  net/net.c        | 3 +++
> >>  qapi-schema.json | 1 +
> >>  2 files changed, 4 insertions(+)
> >> 
> >>  [Note: I'm quite new to this area of the code, please review carefully
> >>   whether this approach makes sense or whether it should be done differently]
> >
> > We thought the QEMU "vlan" concept would be dropped completely in the
> > future, so it was never added to -netdev.  No patches to do that have
> > been posted over the years, so I think it was more of a conceptual goal
> > than a concrete requirement.
> 
> Well, patches to do that first need to replace the VLAN-only dump
> feature.
> 
> To fully deprecate -net, we also have to replace -net nic for
> configuring onboard NICs.
> 
> Prior discussion:
> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
> 
> We haven't really tried either.
> 
> Thomas's patch declares defeat on VLANs: it ports them to -netdev,
> perpetuating the concept.
> 
> > I'm okay with merging this but will leave some time for discussion
> > before merging the patch.
> >
> > "Speak now or forever hold your peace"
> 
> Sure we're ready to give up without having tried?

Seems to me that we'd be better off taking the -netdev arg and
adding a new parameter 'dump=filename' that can be used with any
netdev backend. eg with tap

   -netdev tap,id=foo,fd=3,dump=/somefile,dumplen=1024

The use of a dedicated 'dump' network backend always appear rather
strange as a conceptual approach, and I don't think we should
propagate its use into -netdev

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Stefan Hajnoczi]

On Tue, May 26, 2015 at 3:36 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote:
>> Stefan Hajnoczi <stefanha@redhat.com> writes:
>>
>> > On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
>> >> So far, it is not possible to use the network dump interface
>> >> with the "-netdev" option yet, it only works with the legacy
>> >> "-net" option. To be able to use it with "-netdev", too, this
>> >> patch now enables the "vlan" packet distribution for the
>> >> "-netdev" option, too, so that you can now dump network packets
>> >> like this:
>> >>
>> >> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
>> >>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
>> >>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
>> >>
>> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> >> ---
>> >>  net/net.c        | 3 +++
>> >>  qapi-schema.json | 1 +
>> >>  2 files changed, 4 insertions(+)
>> >>
>> >>  [Note: I'm quite new to this area of the code, please review carefully
>> >>   whether this approach makes sense or whether it should be done differently]
>> >
>> > We thought the QEMU "vlan" concept would be dropped completely in the
>> > future, so it was never added to -netdev.  No patches to do that have
>> > been posted over the years, so I think it was more of a conceptual goal
>> > than a concrete requirement.
>>
>> Well, patches to do that first need to replace the VLAN-only dump
>> feature.
>>
>> To fully deprecate -net, we also have to replace -net nic for
>> configuring onboard NICs.
>>
>> Prior discussion:
>> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
>>
>> We haven't really tried either.
>>
>> Thomas's patch declares defeat on VLANs: it ports them to -netdev,
>> perpetuating the concept.
>>
>> > I'm okay with merging this but will leave some time for discussion
>> > before merging the patch.
>> >
>> > "Speak now or forever hold your peace"
>>
>> Sure we're ready to give up without having tried?
>
> Seems to me that we'd be better off taking the -netdev arg and
> adding a new parameter 'dump=filename' that can be used with any
> netdev backend. eg with tap
>
>    -netdev tap,id=foo,fd=3,dump=/somefile,dumplen=1024
>
> The use of a dedicated 'dump' network backend always appear rather
> strange as a conceptual approach, and I don't think we should
> propagate its use into -netdev

I'm happy with this approach too.

Stefan

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Thomas Huth]

On Tue, 26 May 2015 17:43:09 +0100
Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Tue, May 26, 2015 at 3:36 PM, Daniel P. Berrange <berrange@redhat.com> wrote:
> > On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote:
> >> Stefan Hajnoczi <stefanha@redhat.com> writes:
> >>
> >> > On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
> >> >> So far, it is not possible to use the network dump interface
> >> >> with the "-netdev" option yet, it only works with the legacy
> >> >> "-net" option. To be able to use it with "-netdev", too, this
> >> >> patch now enables the "vlan" packet distribution for the
> >> >> "-netdev" option, too, so that you can now dump network packets
> >> >> like this:
> >> >>
> >> >> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
> >> >>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
> >> >>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
> >> >>
> >> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >> >> ---
> >> >>  net/net.c        | 3 +++
> >> >>  qapi-schema.json | 1 +
> >> >>  2 files changed, 4 insertions(+)
> >> >>
> >> >>  [Note: I'm quite new to this area of the code, please review carefully
> >> >>   whether this approach makes sense or whether it should be done differently]
> >> >
> >> > We thought the QEMU "vlan" concept would be dropped completely in the
> >> > future, so it was never added to -netdev.  No patches to do that have
> >> > been posted over the years, so I think it was more of a conceptual goal
> >> > than a concrete requirement.
> >>
> >> Well, patches to do that first need to replace the VLAN-only dump
> >> feature.
> >>
> >> To fully deprecate -net, we also have to replace -net nic for
> >> configuring onboard NICs.
> >>
> >> Prior discussion:
> >> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
> >>
> >> We haven't really tried either.
> >>
> >> Thomas's patch declares defeat on VLANs: it ports them to -netdev,
> >> perpetuating the concept.
> >>
> >> > I'm okay with merging this but will leave some time for discussion
> >> > before merging the patch.
> >> >
> >> > "Speak now or forever hold your peace"
> >>
> >> Sure we're ready to give up without having tried?
> >
> > Seems to me that we'd be better off taking the -netdev arg and
> > adding a new parameter 'dump=filename' that can be used with any
> > netdev backend. eg with tap
> >
> >    -netdev tap,id=foo,fd=3,dump=/somefile,dumplen=1024
> >
> > The use of a dedicated 'dump' network backend always appear rather
> > strange as a conceptual approach, and I don't think we should
> > propagate its use into -netdev
> 
> I'm happy with this approach too.

I'm certainly fine with both two approaches - as long as the -net vs.
-netdev chaos finally goes away.

However, there is one thing to consider: The "vlans" currently emulate
some kind of hub hardware. If we do not support these with -netdev and
finally remove -net one day, QEMU looses this feature, so that could be
considered as a regression. Question is how useful this feature was
beside connecting it to the dump device, and whether anybody really
used it... for example, when running QEMU inside QEMU with nested
virtualization, could the outer QEMU emulate a hub this way to connect
the two contained virtual machines? OTOH, I think such behavior can
also be reached by different means, so it should be ok to loose this
feature, shouldn't it?

 Thomas

Re: [Qemu-devel] [RFC PATCH] net: Enable vlans and dump for -netdev, too,

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> writes:

> On Tue, 26 May 2015 17:43:09 +0100
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
>> On Tue, May 26, 2015 at 3:36 PM, Daniel P. Berrange
>> <berrange@redhat.com> wrote:
>> > On Tue, May 26, 2015 at 04:29:51PM +0200, Markus Armbruster wrote:
>> >> Stefan Hajnoczi <stefanha@redhat.com> writes:
>> >>
>> >> > On Fri, May 22, 2015 at 09:22:19PM +0200, Thomas Huth wrote:
>> >> >> So far, it is not possible to use the network dump interface
>> >> >> with the "-netdev" option yet, it only works with the legacy
>> >> >> "-net" option. To be able to use it with "-netdev", too, this
>> >> >> patch now enables the "vlan" packet distribution for the
>> >> >> "-netdev" option, too, so that you can now dump network packets
>> >> >> like this:
>> >> >>
>> >> >> qemu... -device e1000,netdev=myhub -netdev hubport,hubid=1,id=myhub \
>> >> >>         -netdev user,id=n1,vlan=1,tftp=/tmp/tftp,bootfile=zImage \
>> >> >>         -netdev dump,id=n2,vlan=1,file=/tmp/dump.dat
>> >> >>
>> >> >> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> >> >> ---
>> >> >>  net/net.c        | 3 +++
>> >> >>  qapi-schema.json | 1 +
>> >> >>  2 files changed, 4 insertions(+)
>> >> >>
>> >> >>  [Note: I'm quite new to this area of the code, please review carefully
>> >> >>   whether this approach makes sense or whether it should be done differently]
>> >> >
>> >> > We thought the QEMU "vlan" concept would be dropped completely in the
>> >> > future, so it was never added to -netdev.  No patches to do that have
>> >> > been posted over the years, so I think it was more of a conceptual goal
>> >> > than a concrete requirement.
>> >>
>> >> Well, patches to do that first need to replace the VLAN-only dump
>> >> feature.
>> >>
>> >> To fully deprecate -net, we also have to replace -net nic for
>> >> configuring onboard NICs.
>> >>
>> >> Prior discussion:
>> >> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
>> >>
>> >> We haven't really tried either.
>> >>
>> >> Thomas's patch declares defeat on VLANs: it ports them to -netdev,
>> >> perpetuating the concept.
>> >>
>> >> > I'm okay with merging this but will leave some time for discussion
>> >> > before merging the patch.
>> >> >
>> >> > "Speak now or forever hold your peace"
>> >>
>> >> Sure we're ready to give up without having tried?
>> >
>> > Seems to me that we'd be better off taking the -netdev arg and
>> > adding a new parameter 'dump=filename' that can be used with any
>> > netdev backend. eg with tap
>> >
>> >    -netdev tap,id=foo,fd=3,dump=/somefile,dumplen=1024
>> >
>> > The use of a dedicated 'dump' network backend always appear rather
>> > strange as a conceptual approach, and I don't think we should
>> > propagate its use into -netdev
>> 
>> I'm happy with this approach too.
>
> I'm certainly fine with both two approaches - as long as the -net vs.
> -netdev chaos finally goes away.
>
> However, there is one thing to consider: The "vlans" currently emulate
> some kind of hub hardware. If we do not support these with -netdev and
> finally remove -net one day, QEMU looses this feature, so that could be
> considered as a regression. Question is how useful this feature was
> beside connecting it to the dump device, and whether anybody really
> used it... for example, when running QEMU inside QEMU with nested
> virtualization, could the outer QEMU emulate a hub this way to connect
> the two contained virtual machines? OTOH, I think such behavior can
> also be reached by different means, so it should be ok to loose this
> feature, shouldn't it?

I wouldn't mind losing the "VLAN" / hub feature.  But if there's a
compelling use for it, I wouldn't mind keeping it, as long as it's out
of the way of users who don't need this niche feature.

So my goal isn't so much "get rid of hubs", it's "deprecate -net", and
"avoid dragging in a hub just for dumping packets".

I want us to deprecate -net, because:

* It forces a hub, which isn't what you want in the common case.

  Related: the default configuration gives you a hub, which is
  sub-optimal for most users.  Needs fixing.  The easiest way to
  configure networking also results in a hub.  Needs fixing, too.

* It's conceptually redundant, thanks to Stefan's hubport work.
  Unfortunately, it still dominates the user interface.

  -net boils down to a network device connected to a hubport, but our
  user interface doesn't let you do the boiling.  It does for -device's
  vlan parameter: you can always replace it by a netdev parameter
  referring to a suitable hubport created with -netdev.  I want the same
  for -net.

* -net nic adds another complication.  Like -serial, -drive if=ide and
  other similarly old options, it doesn't actually do anything, it
  merely sends a message to the board code, which may do with it
  whatever it wants.  Different boards to different things.  Separate
  rabit hole, better avoid it in this thread.

Thomas's patch brings half of what we have in -device to -netdev.
Unfortunately, it's the magic half: the vlan=N parameter to connect to
the hub with hubid=N, magically creating it if it doesn't exist already.
It doesn't bring the non-magic netdev=ID part to connect to an existing
hubport with id=ID.  That's the half I want if we can't get rid of hubs
outright.

-device needs the magic half for backward compatibility.  -netdev
doesn't.  An argument could be made to want it for consistency with
-device.  As far as I'm concerned: no thanks.

Thomas's patch does not address -net nic issues, and that's just fine.

Thomas's patch does not address "avoid dragging in a hub just for
dumping packets".  Dan sketched a way to do that.  It could make sense
even if we decide we want to keep hubs around for other, complicated
applications.

[Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

On 05/26/2015 04:29 PM, Markus Armbruster wrote:
> Stefan Hajnoczi <stefanha@redhat.com> writes:
[...]
>> We thought the QEMU "vlan" concept would be dropped completely in the
>> future, so it was never added to -netdev.  No patches to do that have
>> been posted over the years, so I think it was more of a conceptual goal
>> than a concrete requirement.
> 
> Well, patches to do that first need to replace the VLAN-only dump
> feature.
> 
> To fully deprecate -net, we also have to replace -net nic for
> configuring onboard NICs.
> 
> Prior discussion:
> http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
> 
> We haven't really tried either.

Ok, assuming that my "Network traffic dumping for -netdev devices" patch
series is going to solve the dumping-for-netdev problem, how do we
tackle the remaining problems that we have to solve before we can
deprecate -net? Does anybody have a survey of the (onboard) NICs that
can only be configured with -net but not with -device? Could they
nowadays be changed to work with -device, too, or are there still major
obstacles to solve first?

 Thomas



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)

[Peter Maydell]

On 17 July 2015 at 07:53, Thomas Huth <thuth@redhat.com> wrote:
> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
> series is going to solve the dumping-for-netdev problem, how do we
> tackle the remaining problems that we have to solve before we can
> deprecate -net? Does anybody have a survey of the (onboard) NICs that
> can only be configured with -net but not with -device? Could they
> nowadays be changed to work with -device, too, or are there still major
> obstacles to solve first?

The problem is that "-device" says "create a new device and
configure it like this". But onboard NICs are created by
the board, so we want let the user say how to configure
those devices, not create new ones...

-- PMM

Re: [Qemu-devel] net: Next steps to deprecate -net

[Thomas Huth]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On 07/17/2015 09:25 AM, Peter Maydell wrote:
> On 17 July 2015 at 07:53, Thomas Huth <thuth@redhat.com> wrote:
>> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
>> series is going to solve the dumping-for-netdev problem, how do we
>> tackle the remaining problems that we have to solve before we can
>> deprecate -net? Does anybody have a survey of the (onboard) NICs that
>> can only be configured with -net but not with -device? Could they
>> nowadays be changed to work with -device, too, or are there still major
>> obstacles to solve first?
> 
> The problem is that "-device" says "create a new device and
> configure it like this". But onboard NICs are created by
> the board, so we want let the user say how to configure
> those devices, not create new ones...

Ok, I see ... maybe it makes sense to simply keep "-net nic" to be able
to configure the default/onboard NIC, and only to remove all the other
-net options instead ("-net user" etc.). The disliked vlan/hub concept
could then be removed, too, since "-net nic" can be used together with
"-netdev" nowadays by using something like "-net nic,netdev=xxx" as far
as I know. That would clean up most points of confusion, I think, and
would not cause too much code churn for the onboard NICs. Does that
sound feasible?

 Thomas




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] net: Next steps to deprecate -net

[Markus Armbruster]

Copying Andreas just in case.

Thomas Huth <thuth@redhat.com> writes:

> On 07/17/2015 09:25 AM, Peter Maydell wrote:
>> On 17 July 2015 at 07:53, Thomas Huth <thuth@redhat.com> wrote:
>>> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
>>> series is going to solve the dumping-for-netdev problem, how do we
>>> tackle the remaining problems that we have to solve before we can
>>> deprecate -net? Does anybody have a survey of the (onboard) NICs that
>>> can only be configured with -net but not with -device? Could they
>>> nowadays be changed to work with -device, too, or are there still major
>>> obstacles to solve first?
>> 
>> The problem is that "-device" says "create a new device and
>> configure it like this". But onboard NICs are created by
>> the board, so we want let the user say how to configure
>> those devices, not create new ones...

The more general problem is lack of a uniform way to configure onboard
devices.

We have a bunch of ways to configure onboard devices: -net nic, -serial,
-parallel, -drive, ...  These all deposit configuration requests in
well-known places for the board code to pick up.  A request can apply

(a) to a mandatory onboard device, modifying its configuration, or

(b) to an optional onboard device, triggering its creation, or

(c) to nothing in particular.

It all depends on the board code.

For qdevified devices, you can replace (b) with -device, but not (a), as
Peter points out.

To likewise replace (a), we'd need means to change an *existing*
device's properties.  Complication: how to address the device.  Onboard
devices don't have a qdev ID...  QOM path?

Aside: you can sometimes use -global to replace (a), but it's not
general, because -global applies to all devices of a certain type, not
just the one you're actually targeting.

> Ok, I see ... maybe it makes sense to simply keep "-net nic" to be able
> to configure the default/onboard NIC, and only to remove all the other
> -net options instead ("-net user" etc.). The disliked vlan/hub concept
> could then be removed, too, since "-net nic" can be used together with
> "-netdev" nowadays by using something like "-net nic,netdev=xxx" as far
> as I know. That would clean up most points of confusion, I think, and
> would not cause too much code churn for the onboard NICs. Does that
> sound feasible?

Deprecating -net except for -net nic sounds like a fine step forward to
me.

Re: [Qemu-devel] net: Next steps to deprecate -net

[Michael S. Tsirkin]

On Wed, Jul 22, 2015 at 03:40:55PM +0200, Markus Armbruster wrote:
> Copying Andreas just in case.
> 
> Thomas Huth <thuth@redhat.com> writes:
> 
> > On 07/17/2015 09:25 AM, Peter Maydell wrote:
> >> On 17 July 2015 at 07:53, Thomas Huth <thuth@redhat.com> wrote:
> >>> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
> >>> series is going to solve the dumping-for-netdev problem, how do we
> >>> tackle the remaining problems that we have to solve before we can
> >>> deprecate -net? Does anybody have a survey of the (onboard) NICs that
> >>> can only be configured with -net but not with -device? Could they
> >>> nowadays be changed to work with -device, too, or are there still major
> >>> obstacles to solve first?
> >> 
> >> The problem is that "-device" says "create a new device and
> >> configure it like this". But onboard NICs are created by
> >> the board, so we want let the user say how to configure
> >> those devices, not create new ones...
> 
> The more general problem is lack of a uniform way to configure onboard
> devices.
> 
> We have a bunch of ways to configure onboard devices: -net nic, -serial,
> -parallel, -drive, ...  These all deposit configuration requests in
> well-known places for the board code to pick up.  A request can apply
> 
> (a) to a mandatory onboard device, modifying its configuration, or
> 
> (b) to an optional onboard device, triggering its creation, or
> 
> (c) to nothing in particular.
> 
> It all depends on the board code.
> 
> For qdevified devices, you can replace (b) with -device, but not (a), as
> Peter points out.
> 
> To likewise replace (a), we'd need means to change an *existing*
> device's properties.  Complication: how to address the device.  Onboard
> devices don't have a qdev ID...  QOM path?
> 
> Aside: you can sometimes use -global to replace (a), but it's not
> general, because -global applies to all devices of a certain type, not
> just the one you're actually targeting.
> 
> > Ok, I see ... maybe it makes sense to simply keep "-net nic" to be able
> > to configure the default/onboard NIC, and only to remove all the other
> > -net options instead ("-net user" etc.). The disliked vlan/hub concept
> > could then be removed, too, since "-net nic" can be used together with
> > "-netdev" nowadays by using something like "-net nic,netdev=xxx" as far
> > as I know. That would clean up most points of confusion, I think, and
> > would not cause too much code churn for the onboard NICs. Does that
> > sound feasible?
> 
> Deprecating -net except for -net nic sounds like a fine step forward to
> me.

-net dump is also useful, we'll need some solution for that if we
want to deprecate vlans.

-- 
MST

Re: [Qemu-devel] net: Next steps to deprecate -net

[Thomas Huth]

On 22/07/15 18:20, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2015 at 03:40:55PM +0200, Markus Armbruster wrote:
...
>> Deprecating -net except for -net nic sounds like a fine step forward to
>> me.
> 
> -net dump is also useful, we'll need some solution for that if we
> want to deprecate vlans.

*cough* see my patch series at:
  http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg02771.html

 Thomas

Re: [Qemu-devel] net: Next steps to deprecate -net (was: [RFC PATCH] Enable vlans and dump for -netdev, too)

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

On Fri, Jul 17, 2015 at 08:53:08AM +0200, Thomas Huth wrote:
> On 05/26/2015 04:29 PM, Markus Armbruster wrote:
> > Stefan Hajnoczi <stefanha@redhat.com> writes:
> [...]
> >> We thought the QEMU "vlan" concept would be dropped completely in the
> >> future, so it was never added to -netdev.  No patches to do that have
> >> been posted over the years, so I think it was more of a conceptual goal
> >> than a concrete requirement.
> > 
> > Well, patches to do that first need to replace the VLAN-only dump
> > feature.
> > 
> > To fully deprecate -net, we also have to replace -net nic for
> > configuring onboard NICs.
> > 
> > Prior discussion:
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg03743.html
> > 
> > We haven't really tried either.
> 
> Ok, assuming that my "Network traffic dumping for -netdev devices" patch
> series is going to solve the dumping-for-netdev problem, how do we
> tackle the remaining problems that we have to solve before we can
> deprecate -net? Does anybody have a survey of the (onboard) NICs that
> can only be configured with -net but not with -device? Could they
> nowadays be changed to work with -device, too, or are there still major
> obstacles to solve first?

Take a look at nd_table[] and nb_nics.  That's the array of -net nic
devices.  The boards look into the array to grab NICs.

The default NIC is set in net_init_clients() as a "-net nic" option.

The weird thing about "-net nic" is that the device is not created in
net/net.c by the "-net nic" command-line option.  It just adds the
information to the nd_table[] array.

It's the board that has to instantiate nd_table[] entries.  For example,
pc_nic_init() adds devices for x86 guests.

That's about all I know or have thought about so far.  It would be nice
to get rid of -net but it will take some work and is a QEMU 3.0 feature
since it breaks backwards compatibility.

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]