Print an error if the user specifies vnet_hdr=1 on the cmdline.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
net_tap_init() always sets vnet_hdr using qemu_opt_get_bool(), but
initialize it in net_init_tap() just to reduce confusion.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add a NetClientInfo pointer to VLANClientState and use that
for the typecode and function pointers.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
... and VLANClientState::opaque and qemu_find_vlan_client().
All of these are now unused
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Common state for all NICs.
The opaque member will replace the opaque member in VLANClientState
since only NICs need it.
The conf member will allow us to iterate over NICs, access the MAC
addr for the NIC and send a packet from each NIC in qemu_announce_self().
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Nothing qdev specific about this, make it available throughtout.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
A replacement for qemu_new_vlan_client(), using NetClientInfo to
replace most arguments.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This structure holds data which is common to all instances of a given
net client type/model.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Since 1cc33683, this field is not set for most devices, so just
remove it and its remaining few uses.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is probably a little drastic, but the includes in this file are
now totally out of control when compared with what includes are
actually needed.
This may break the build on e.g. *BSD, but it will be easily fixed by
re-instating an include.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Okay, let's try re-enabling the drain-entire-queue behaviour, with a
difference - before each subsequent packet, use qemu_can_send_packet()
to check that we can send it. This is similar to how we check before
polling the tap fd and avoids having to drop a packet if the receiver
cannot handle it.
This patch should be a performance improvement since we no longer have
to go through the mainloop for each packet.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We should only return zero from receive() for a condition which we'll
get notification of when it changes. Currently, we're returning zero
if the guest driver is not ready, but we won't ever flush our queue
when that status changes.
Also, don't check buffer space in can_receive(), but instead just allow
receive() to return zero when this condition occurs and have the caller
handle queueing the packet.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now that we disable any receiver whose queue is full, we do not require
senders to handle a zero return by supplying a sent callback.
This is a second step towards allowing can_receive() handlers to return
true even if no buffer space is available.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If a receiver returns zero, that means its queue is full and it will
notify us when room is available using qemu_flush_queued_packets().
Take note of that and disable that receiver until it flushes its queue.
This is a first step towards allowing can_receive() handlers to return
true even if no buffer space is available.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If qemu_send_packet_async() returns zero, it means the packet has been
queued and the sent callback will be invoked once it has been flushed.
This is only possible where the NIC's receive() handler returns zero
and promises to notify the networking core that room is available in its
queue again.
In the case where the receive handler does not have this capability
(and its queue fills up) it returns -1 and the networking core does not
queue up the packet. This condition is indicated by a -1 return from
qemu_send_packet_async().
Currently, tap handles this condition simply by dropping the packet. It
should do its best to avoid getting into this situation by checking such
NIC's have room for a packet before copying the packet from the tap
interface.
tap_send() used to achieve this by only reading a single packet before
returning to the mainloop. That way, tap_can_send() is called before
reading each packet.
tap_send() was changed to completely drain the tap interface queue
without taking into account the situation where the NIC returns an
error and the packet is not queued. Let's start fixing this by
reverting to the previous behaviour of reading one packet at a time.
Reported-by: Scott Tsai <scottt.tw@gmail.com>
Tested-by: Sven Rudolph <Sven_Rudolph@drewag.de>
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit:
commit 97b15621
virtio: use qdev properties for configuration.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
makes a guest using virtio-net see an empty macaddr because we never
copy the macaddr into the location that virtio_net_get_config() uses.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
So I can add a tap-linux.c and use CONFIG_LINUX to pull it in
in Makefile
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Okay, this makes the tap options available on AIX even though there's
no support, but if we want to do it right we should have not compile
the tap code at all on AIX using e.g. CONFIG_TAP.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If we tell the guest we support UFO and then migrate to host which
doesn't support it, we will find ourselves in grave difficulties.
Prevent this scenario by adding a flag to virtio-net's savevm format
which indicates whether the device requires host UFO support.
[v2:
- add has_ufo uint8_t field for ease of vmstate conversion
- use qemu_error()
]
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We query the guest's feature set to see if it supports offload and,
if so, we enable those features on the tap interface.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This API allows virtio-net to enable various offload features on a
tap interface - e.g. to tell the host kernel it can pass up partial
checksums to userspace.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
With '-netdev tap,id=foo -nic model=virtio,netdev=foo' virtio-net can
detect that its peer (i.e. the tap backend) supports vnet headers
and advertise to the guest that it can send packets with partial
checksums and/or TSO packets.
One complication is that if we're migrating and the source host
supports IFF_VNET_HDR but the destination host doesn't, we can't then
stop the guest from using those features. In this scenario, we just
fail the migration.
[v2:
- add has_vnet_hdr uint32_t field for ease of vmstate conversion
- use qemu_error()
]
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
tap_receive_raw() always prepends a vnet header if IFF_VNET_HDR is
enabled.
tap_receive() only prepends when the a header is required but the NIC
doesn't supply one.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Trivial patch to allow supplying a receive_raw function.
A future cleanup should combine this function pointer parameters into a
table.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In the case where a NIC and backend agree on a packet header format,
this API allows injecting packets which lack the agreed upon header.
We need this for sending our gratuitous ARP.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This allows for the addition of a raw flag, and leaves the way open
for other flags too.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
These lamely named functions allow virtio-net to query whether
IFF_VNET_HDR is enabled on a tap interface and inform the tap code
that virtio-net will supply packets with a vnet header.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is so as to allow APIs which operate on specific client types
without having to add a function table entry which is only implemented
by a single client type.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This allows people to disable the IFF_VNET_HDR flag, e.g. for debugging
purposes or if they know they may migrate the guest to a machine without
IFF_VNET_HDR support.
It also allows making the lack of IFF_VNET_HDR support an error
condition, e.g. in the case where a guest is being migrated from a host
which does support it.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Re-factor things so that there is only one call site for
net_tap_fd_init().
Two concerns about the QemuOpts usage here - firstly, we set the script
arguments to their default value and, secondly, we set the ifname value
to the name allocated by the kernel if none is supplied. Are we okay
with such things ending up in writeconfig output?
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
For now, we just add an empty header before writing and strip the header
after reading.
We really only want IFF_VNET_HDR when virtio_net is using it, but it
would significantly complicate matters to try and do that. There should
be little or no performance impact with always adding headers.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
In future we will want to prepend a virtio_net header if the NIC didn't
supply one but IFF_VNET_HDR is enabled on the interface. This is most
easily achived by using writev() in all cases.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Making features dependent on the availability of newer versions if_tun.h
is going to get seriously clumsy, so let's just import the definitions
we need. It's only a small handful.
If and when we're comfortable depending on 2.6.30 headers, we can remove
this again.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Looks like these are just artifacts of vl.c being split up.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
For NICs, net_init_client() returns the index into the NICInfo table.
qemu_opts_foreach() interprets non-zero as an error return an stops
iterating over the options.
So, if you have more than one '-net nic' on the command line, subsequent
'-net' options do not get processed.
Fix this by making net_client_init() only return non-zero if
net_init_client() returns an error.
Reported-by: Peter Lieven <pl@dlh.net>
Patchworks-ID: 35736
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now that we have re-factored the packet queue code, we can re-use
it for peer-to-peer also.
Patchworks-ID: 35520
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The packet queue code is fairly standalone, has some complex details and
easily reusable. It makes sense to split it out on its own. This patch
doesn't contain any functional changes.
Patchworks-ID: 35511
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Introduce a 'peer' member to VLANClientState as an alternative
to a vlan. The idea being that packets are transfered directly
from peer clients rather than going through a vlan.
Patchworks-ID: 35516
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Allows them to be cleaned up at shutdown.
This is pretty lame, but will eventually go away as we make vlans
the special case.
Patchworks-ID: 35518
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Same as for -net except for:
- only tap, user, vde and socket types are supported
- the vlan parameter is not allowed
- the name parameter is not allowed but the id parameter is
required
Patchworks-ID: 35517
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Allow net clients to be created which are not connected to any vlan.
This is needed by Gerd in order to allow adding -device nic, where
the absence of a vlan parameter will not imply vlan=0. Also needed
to allow adding a -netdevice option which doesn't connect the backend
to a vlan.
Patchworks-ID: 35513
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Just use the name field instead since we now use the id paramater as
the name, if supplied. Only implication with this change is that if
id is not supplied, the value of the name paramater is used as an
id.
Patchworks-ID: 35512
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Use id= in the same was as the current name= parameter; if both are
specified, id= is used.
Patchworks-ID: 35514
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Needed for e.g. looking up a file descriptor name using
monitor_get_fd() in net_init_tap()
Patchworks-ID: 35509
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Without this, I'm seeing a segfault when unpluging a NIC.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Patchworks-ID: 35519
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Now that net_client_init() has no users, kill it off and rename
net_client_init_from_opts().
There is no further need for the old code in net_client_parse() either.
We use qemu_opts_parse() 'firstname' facitity for that. Instead, move
the special handling of the 'vmchannel' type there.
Simplify the vl.c code into merely call net_client_parse() for each
-net command line option and then calling net_init_clients() later
to iterate over the options and create the clients.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We need net_client_init_from_opts() exported for this
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Here is where we rely on qemu_opts_parse() to handle an empty string.
We could alternatively explicitly handle this here by using
qemu_opts_create() when we're not supplied any parameters, but its
cleaner this way.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Mark McLoughlin