[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] using -net dump with tap networking
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] using -net dump with tap networking |
Date: |
Fri, 22 Feb 2013 12:51:33 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
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).
> 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!).
Paolo
> 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.
>
- Re: [Qemu-devel] using -net dump with tap networking, (continued)
- Re: [Qemu-devel] using -net dump with tap networking, Stefan Hajnoczi, 2013/02/19
- Re: [Qemu-devel] using -net dump with tap networking, Markus Armbruster, 2013/02/19
- Re: [Qemu-devel] using -net dump with tap networking, Stefan Hajnoczi, 2013/02/19
- Re: [Qemu-devel] using -net dump with tap networking, Markus Armbruster, 2013/02/19
- Re: [Qemu-devel] using -net dump with tap networking, Laszlo Ersek, 2013/02/19
- Re: [Qemu-devel] using -net dump with tap networking, Stefan Hajnoczi, 2013/02/20
- Re: [Qemu-devel] using -net dump with tap networking, Markus Armbruster, 2013/02/21
- Re: [Qemu-devel] using -net dump with tap networking, Paolo Bonzini, 2013/02/21
- Re: [Qemu-devel] using -net dump with tap networking, Markus Armbruster, 2013/02/22
- Re: [Qemu-devel] using -net dump with tap networking, Jan Kiszka, 2013/02/22
- Re: [Qemu-devel] using -net dump with tap networking,
Paolo Bonzini <=
- Re: [Qemu-devel] using -net dump with tap networking, Markus Armbruster, 2013/02/22
- Re: [Qemu-devel] using -net dump with tap networking, Stefan Hajnoczi, 2013/02/20
- Re: [Qemu-devel] using -net dump with tap networking, Laszlo Ersek, 2013/02/19