similar to: [net-next V7 PATCH] virtio-net: send gratuitous packets when needed

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packet when needed. Guest test VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v3: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packet when needed. Guest test VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v3: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v5: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v5: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v4: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v4: -

On Sun, 5 Oct 2014 19:07:13 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't arrive during probing, > drop config_enable flag in virtio net. > On removal, flush is now sufficient to guarantee that no change work is > queued. > > This help simplify the driver, and will allow setting DRIVER_OK earlier

On Sun, 5 Oct 2014 19:07:13 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't arrive during probing, > drop config_enable flag in virtio net. > On removal, flush is now sufficient to guarantee that no change work is > queued. > > This help simplify the driver, and will allow setting DRIVER_OK earlier

Fix a theoretical race related to config work handler: a config interrupt might happen after we flush config work but before we reset the device. It will then cause the config work to run during or after reset. Two problems with this: - if this runs after device is gone we will get use after free - access of config while reset is in progress is racy (as layout is changing). As a solution 1.

Fix a theoretical race related to config work handler: a config interrupt might happen after we flush config work but before we reset the device. It will then cause the config work to run during or after reset. Two problems with this: - if this runs after device is gone we will get use after free - access of config while reset is in progress is racy (as layout is changing). As a solution 1.

On Sun, 5 Oct 2014 19:07:07 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't > arrive during probing, drop config_enable flag > in virtio blk. > On removal, flush is now sufficient to guarantee that > no change work is queued. > > This help simplify the driver, and will allow > setting DRIVER_OK

On Sun, 5 Oct 2014 19:07:07 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > Now that virtio core ensures config changes don't > arrive during probing, drop config_enable flag > in virtio blk. > On removal, flush is now sufficient to guarantee that > no change work is queued. > > This help simplify the driver, and will allow > setting DRIVER_OK

Rusty, I have a mind to send this patches for the next merge window. Any input on this? This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a

Rusty, I have a mind to send this patches for the next merge window. Any input on this? This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a

Rusty, I have a mind to include this patchset for this merge window. Any input on this? This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a

Rusty, I have a mind to include this patchset for this merge window. Any input on this? This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a

Rusty, please review this, and consider for this merge window. This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a clear violation of virtio

Rusty, please review this, and consider for this merge window. This fixes the following virtio spec compliance issues: 1. on restore, drivers use device before setting ACKNOWLEDGE and DRIVER bits 2. on probe, drivers aren't prepared to handle config interrupts arriving before probe returns 3. on probe, drivers use device before DRIVER_OK it set Note that 1 is a clear violation of virtio

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR

Hello All: This series is an update version of multiqueue virtio-net driver based on Krishna Kumar's work to let virtio-net use multiple rx/tx queues to do the packets reception and transmission. Please review and comments. Test Environment: - Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes - Two directed connected 82599 Test Summary: - Highlights: huge improvements on TCP_RR