Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Also add a new net/checksum.h header
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony 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: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Enable UFO on the host tap device if supported and allow setting UFO
on virtio-net in the guest.
Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

With the latest GSO/csum offload patches, any guest using an unpatched version
of dhclient (any Ubuntu guest, for instance), will no longer be able to get
a DHCP address.

dhclient is actually at fault here.  It uses AF_PACKET to receive DHCP responses
but does not check auxdata to see if the packet has a valid csum.  This causes
it to throw out the DHCP responses it gets from the virtio interface as there
is not a valid checksum.

Fedora has carried a patch to fix their dhclient (it's needed for Xen too) but
this patch has not made it into a release of dhclient.  AFAIK, the patch is in
the dhclient CVS but I cannot confirm since their CVS is not public.

This patch, suggested by Rusty, looks for UDP packets (of a normal MTU) and
explicitly adds a checksum to them if they are missing one.

This allows unpatched dhclients to continue to work without needing to update
the guest kernels.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony 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: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony 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: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

This is a backport from qemu-kvm. Just instead of using kvm's specific
notification mechanism, we use qemu_notify_event()
Signed-off-by: NGlauber Costa <glommer@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Add an option to specify the number of MSI-X vectors for PCI NIC cards. This
can also be used to disable MSI-X, for compatibility with old qemu. This
option currently only affects virtio cards.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Request up to 3 vectors in virtio-net. Actual bindings might supply
less.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

When virtio-net was merged in from qemu-kvm.git, the VNET_HDR related
features were dropped from the code.

However, VIRTIO_NET_F_MRG_RXBUF appears to have accidentally been
dropped too. Re-instate that now.
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Increase the size of the perfect filter table and control queue depth.
This should give us more headroom in the MAC filter and is known to be
needed by at least one guest user.  Increasing the control queue depth
allows a guest to feed several commands back to back if they so desire
rather than using the send and wait approach Linux uses.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Add a few new RX modes to better control the receive_filter.  These
are all fairly obvious features that hardware could provide.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

The MAC filter table is received from the guest as two separate
buffers, one with unicast entries, the other with multicast
entries.  If we track the index dividing the two sets, we can
avoid searching the part of the table with the wrong type of
entries.

We could store this index as part of the save image, but its
trivially easy to discover it on load.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Overloading the promisc and allmulti flags for indicating filter
table overflow makes it difficult to track the actual requested
operating mode.  Split these out into separate flags.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Reorganize receive_filter to better handle the split between
unicast and multicast filtering.  This allows us to skip the
broadcast check on unicast packets and leads to more opportunities
for optimization.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

There's no need to save 4 bytes for promisc and allmulti.
Use one byte each just to avoid the overhead of a bitmap.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

If we don't have room to receive a packet, we return zero
from virtio_net_receive() and call qemu_flush_queued_packets()
as soon as space becomes available.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

This allows us to handle queue full conditions rather than dropping
the packet on the floor.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Give static type checking a chance to catch errors.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

VLANClientState's fd_read() handler doesn't read from file
descriptors, it adds a buffer to the client's receive queue.

Re-name the handlers to make things a little less confusing.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

This, apparently, is the style we prefer - all VLANClientState
should be an argument to qemu_new_vlan_client().
Signed-off-by: NMark McLoughlin <markmc@redhat.com>

Split the PCI host bindings from the VRing transport implementation.
Signed-off-by: NPaul Brook <paul@codesourcery.com>

Signed-off-by: NPaul Brook <paul@codesourcery.com>

We're currently leaking memory and file descriptors on device
hot-unplug.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7150 c046a42c-6fe2-441c-8c8c-71466251a162

Obviously merged from kvm-userspace accidentally.
Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7142 c046a42c-6fe2-441c-8c8c-71466251a162

git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7103 c046a42c-6fe2-441c-8c8c-71466251a162

I believe this is behind the following:
https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128

virtio_pci in 2.6.25 didn't do feature negotiation correctly: it acked every
bit.  Fortunately, we can detect this.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6975 c046a42c-6fe2-441c-8c8c-71466251a162

When checking that the size of the control virtqueue return field
is sufficient, use the correct sg list.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6845 c046a42c-6fe2-441c-8c8c-71466251a162

No need to check for failing qemu_malloc anymore.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>



git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6626 c046a42c-6fe2-441c-8c8c-71466251a162

Change the PCI network drivers init functions to return the PCIDev, to
inform which slot has been hot-plugged.

Also record PCIDevice structure on NICInfo to locate for release on
hot-removal.
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6593 c046a42c-6fe2-441c-8c8c-71466251a162

Use the control virtqueue to allow the guest to enable and manipulate
a VLAN filter table.  This allows us to drop more packets the guest
doesn't want to see.  We define a new VLAN class for the control
virtqueue with commands ADD and DEL with usage defined in virtio-net.h.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6540 c046a42c-6fe2-441c-8c8c-71466251a162

Create a filter table and allow the guest to populate it with the
MAC class control commands.  We manage the size and usage of the
filter table including enabling promiscuous and all-multi modes
as necessary.  The guest should therefore assume the table is
infinite.  Eventually this might allow us to bind directly to a
hardware NIC and manipulate a physical MAC filter.

The specifics of the TABLE_SET command are documented in
virtio-net.h.  Separate buffers in the same command are used
for unicaste and multicast addresses for priority and
sychronization.  With this we can export the VIRTIO_NET_F_CTRL_RX
feature bit.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6539 c046a42c-6fe2-441c-8c8c-71466251a162

Make use of the new RX_MODE control virtqueue class by dropping
packets the guest doesn't want to see.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6538 c046a42c-6fe2-441c-8c8c-71466251a162

Add a new RX_MODE control virtqueue class with commands PROMISC and
ALLMULTI and usage documented in virtio-net.h allowing the guest to
manipulate packet receiving options.  We don't export a feature for
this until we also add the MAC filter table.

Note, for compatibility with older guest drivers we need to default
to promiscuous.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6537 c046a42c-6fe2-441c-8c8c-71466251a162

This will be used for RX mode, MAC table, VLAN table control, etc...

The control transaction consists of one or more "out" sg entries and
one or more "in" sg entries.  The first out entry contains a header
defining the class and command.  Additional out entries may provide
data for the command.  A response via the ack entry is required
and the guest will typically be waiting for it.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6536 c046a42c-6fe2-441c-8c8c-71466251a162

Makes it much easier to search too.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6535 c046a42c-6fe2-441c-8c8c-71466251a162