Re: [Qemu-devel] using -net dump with tap networking

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> Il 22/02/2013 10:35, Markus Armbruster ha scritto:
>> Paolo Bonzini <address@hidden> writes:
>> 
>>> Il 21/02/2013 15:41, Markus Armbruster ha scritto:
>>>> Trouble is the user interface is as confusing as ever.  Worse, in a way,
>>>> because we now have to explain how "vlan" and the hubport netdev relate.
>>>>
>>>> Permit me a brief rant.  Have you read the manual page on -netdev and
>>>> -net recently?  Have you tried to explain setting up QEMU networking to
>>>> a neophyte?  Were you able to keep a straight face?  If yes, congrats,
>>>> you got a great future ahead of you.
>>>>
>>>> We have so many ways to do the same thing, complicating our docs
>>>> enormously.  Just one of them makes sense for almost all uses, but I
>>>> doubt mortal users could guess which one just from the docs.
>>>>
>>>> Can we do for the docs what Stefan did for the code, i.e. get "vlans"
>>>> out of the way?
>>>>
>>>> Specifically, what's missing to let us deprecate -net completely?
>>>
>>> Less important: the fact that "-net dump" is quite useful and requires
>>> vlans.
>> 
>> Let me rephrase: dumping network traffic is quite useful, and our
>> current way to do that from within QEMU requires "vlans".
>> 
>> The "dump" vlan client is neither a net frontend nor a net backend, it's
>> a passive listener.  Could also be viewed as special case of a filter
>> that happens not to change anything.
>> 
>> If it's the only useful listener or filter, we could just special-case
>> it and be done.
>> 
>> If not, we need a way to attach listeners to the 1:1 netdev connections,
>> or turn it in a chain with filters as interior nodes.
>> 
>>>        ("-net socket" has some usecases too: "-net bridge" helps placing
>>> a VM's network on a bridge, but adding a bridge still requires root
>>> privileges).
>> 
>> "-netdev socket" and "-netdev bridge" don't cut it?
>
> "-netdev bridge" works great.
>
> If you want to bridge multiple guest NICs on the same socket, however,
> you need the VLAN mechanism (though actually you can also use "-netdev
> socket,mcast" if that works).

I don't mind keeping "vlans" around for somewhat exotic use cases, now
that Stefan restructured the code to get them out of the way.  I'm
looking for ways to get a similar improvement in the user interface.
Right now, qemu(1) mentions "vlan" first, and netdev second, if at all.
Additionally, I'm wondering whether we can further reduce "vlan" use
cases.

>> To be more precise: -device currently works only for devices on
>> pluggable buses.
>> 
>> Anything you could plug on a physical machine should be on a pluggable
>> bus (whether we implemented plugging is another question).
>> 
>> Anything you couldn't plug on a physical machine must be soldered onto
>> the board.  Boards often come in a few flavours with different onboard
>> devices.  Virtual boards tend to sprout more flavours.  Because of that,
>> thinking in board options you can combine is often more convenient than
>> having a finite number of board variants.
>> 
>> QOM will hopefully enable us to stitch devices together without the need
>> for buses.
>
> Still, you have to tell the board "this is NIC 0", because it is the
> board logic that knows the MMIO base address of the NICs---not the NIC
> itself.
>
> At least, that's how the authors of embedded ports structure their code
> (see recent disappearance of sysbus_add_memory; enabling pervasive use
> of "-device" would instead require sysbus_mmio_map to disappear!).

To be precise: you tell the board how you want NIC 0 configured.

My argument is that "-net nic" is a lousy way to do that.  In more
detail:

>> So, I quite agree that we need a way to configure board options.  Our
>> current way to do that for NICs is multiplexed into -net as "-net nic".
>> 
>> "-net nic" is quite unlike the other -net: it doesn't create a vlan
>> client, it asks the board to create a NIC device.  Parameter "model"
>> lets you ask for a specific one.
>> 
>> Boards can do what they want with these requests.  Some boards don't
>> support NICs and simply ignore these requests (generic code attempts to
>> detect that and warn).  Others treat models they don't know as fatal
>> error.  Some boards create exactly the NICs you asked for.  Others
>> create exactly their onboard NICs, whether you asked for them or not
>> (asking is merely a way to supply configuration parameters).
>> 
>> Most (all?) boards can tell you what models they support (-net
>> nic,model=help), but some lie, e.g. PCs neglect to mention model
>> ne2k_isa.
>> 
>> Boards supporting PCI generally recognize a few common PCI NIC models.
>> But you're better off using -device there, because it gives you access
>> to all device models and options at no extra charge.
>> 
>> "Well, here's another nice mess you've gotten me into, Stanley!"
>> 
>> 
>> TL;DR: I quite agree that we can't just throw away -net without a
>> replacement.  I just think it's a mess, and should be replaced.