| Message ID | 20221019125210.226291-1-eperezma@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Guest announce feature emulation using Shadow VirtQueue | expand |
On Wed, Oct 19, 2022 at 8:52 PM Eugenio Pérez <eperezma@redhat.com> wrote: > > A gratuitous ARP is recommended after a live migration to reduce the amount of > time needed by the network links to be aware of the new location. A question: I think we need to deal with the case when GUSET_ANNOUNCE is not negotiated? E.d sending the gARP by ourselves via vhost-vDPA? Thanks > A hypervisor > may not have the knowledge of the guest network configuration, and this is > especially true on passthrough devices, so its simpler to ask the guest to > do it. > > However, the device control part of this feature can be totally emulated by > qemu and shadow virtqueue, not needing any special feature from the actual > vdpa device. > > VIRTIO_NET_F_STATUS is also needed for the guest to access the status of > virtio net config where announcement status bit is set. Emulating it as > always active in case backend does not support it. > > v2: > * Add VIRTIO_NET_F_STATUS emulation. > > Eugenio Pérez (8): > vdpa: Delete duplicated vdpa_feature_bits entry > vdpa: Save emulated features list in vhost_vdpa > vhost_net: Emulate link state up if backend doesn't expose it > vdpa: Expose VIRTIO_NET_F_STATUS unconditionally > vdpa: Remove shadow CVQ command check > vdpa: handle VIRTIO_NET_CTRL_ANNOUNCE in > vhost_vdpa_net_handle_ctrl_avail > vhost_net: return VIRTIO_NET_S_ANNOUNCE is device model has it set > vdpa: Offer VIRTIO_NET_F_GUEST_ANNOUNCE feature if SVQ is enabled > > include/hw/virtio/vhost-vdpa.h | 2 + > hw/net/vhost_net.c | 35 +++++++++++++++- > hw/virtio/vhost-vdpa.c | 8 ++-- > net/vhost-vdpa.c | 74 ++++++++++------------------------ > 4 files changed, 62 insertions(+), 57 deletions(-) > > -- > 2.31.1 > >
On Thu, Oct 20, 2022 at 6:24 AM Jason Wang <jasowang@redhat.com> wrote: > > On Wed, Oct 19, 2022 at 8:52 PM Eugenio Pérez <eperezma@redhat.com> wrote: > > > > A gratuitous ARP is recommended after a live migration to reduce the amount of > > time needed by the network links to be aware of the new location. > > A question: I think we need to deal with the case when GUSET_ANNOUNCE > is not negotiated? E.d sending the gARP by ourselves via vhost-vDPA? > That is possible and I totally agree to implement it on top of this series, but it complicates the code in two ways: 1. The startup will be slower and more complicated. We can only send the gARP from qemu using SVQ. At this point SVQ in dataplane is always enabled as long as cmdline x-svq is on, but in the final form it will not be the case, and dataplane will be passthrough. If we want to send gARP from qemu, this will imply to start the device all in SVQ, and then reset it to its final configuration. 2. Qemu may not know the actual guest state For example, regarding the mac filtering qemu will simply allow all unicast if too many macs are configured in the device, not saving them individually. However, I think it is better than nothing for the guest that does not support GUEST_ANNOUNCE so, as said, I'm ok to implement it on top of this series for sure. But I think other features should have more priority, isn't it? Thanks! > Thanks > > > A hypervisor > > may not have the knowledge of the guest network configuration, and this is > > especially true on passthrough devices, so its simpler to ask the guest to > > do it. > > > > However, the device control part of this feature can be totally emulated by > > qemu and shadow virtqueue, not needing any special feature from the actual > > vdpa device. > > > > VIRTIO_NET_F_STATUS is also needed for the guest to access the status of > > virtio net config where announcement status bit is set. Emulating it as > > always active in case backend does not support it. > > > > v2: > > * Add VIRTIO_NET_F_STATUS emulation. > > > > Eugenio Pérez (8): > > vdpa: Delete duplicated vdpa_feature_bits entry > > vdpa: Save emulated features list in vhost_vdpa > > vhost_net: Emulate link state up if backend doesn't expose it > > vdpa: Expose VIRTIO_NET_F_STATUS unconditionally > > vdpa: Remove shadow CVQ command check > > vdpa: handle VIRTIO_NET_CTRL_ANNOUNCE in > > vhost_vdpa_net_handle_ctrl_avail > > vhost_net: return VIRTIO_NET_S_ANNOUNCE is device model has it set > > vdpa: Offer VIRTIO_NET_F_GUEST_ANNOUNCE feature if SVQ is enabled > > > > include/hw/virtio/vhost-vdpa.h | 2 + > > hw/net/vhost_net.c | 35 +++++++++++++++- > > hw/virtio/vhost-vdpa.c | 8 ++-- > > net/vhost-vdpa.c | 74 ++++++++++------------------------ > > 4 files changed, 62 insertions(+), 57 deletions(-) > > > > -- > > 2.31.1 > > > > >
A gratuitous ARP is recommended after a live migration to reduce the amount of time needed by the network links to be aware of the new location. A hypervisor may not have the knowledge of the guest network configuration, and this is especially true on passthrough devices, so its simpler to ask the guest to do it. However, the device control part of this feature can be totally emulated by qemu and shadow virtqueue, not needing any special feature from the actual vdpa device. VIRTIO_NET_F_STATUS is also needed for the guest to access the status of virtio net config where announcement status bit is set. Emulating it as always active in case backend does not support it. v2: * Add VIRTIO_NET_F_STATUS emulation. Eugenio Pérez (8): vdpa: Delete duplicated vdpa_feature_bits entry vdpa: Save emulated features list in vhost_vdpa vhost_net: Emulate link state up if backend doesn't expose it vdpa: Expose VIRTIO_NET_F_STATUS unconditionally vdpa: Remove shadow CVQ command check vdpa: handle VIRTIO_NET_CTRL_ANNOUNCE in vhost_vdpa_net_handle_ctrl_avail vhost_net: return VIRTIO_NET_S_ANNOUNCE is device model has it set vdpa: Offer VIRTIO_NET_F_GUEST_ANNOUNCE feature if SVQ is enabled include/hw/virtio/vhost-vdpa.h | 2 + hw/net/vhost_net.c | 35 +++++++++++++++- hw/virtio/vhost-vdpa.c | 8 ++-- net/vhost-vdpa.c | 74 ++++++++++------------------------ 4 files changed, 62 insertions(+), 57 deletions(-)