search for: link_announce

...> > I have a question here though. How do things like MAC address > get restored? > > What about the rx mode? > > vlans? The function as is releases and reinitializes only ring state. Device configuration such as mac and vlan persist across the reset. > Also, it seems that LINK_ANNOUNCE requests will get ignored > even if they got set before the reset, leading to downtime. Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE requests? That flag is tested and netdev_notify_peers called before resetting virtio ring state.

...> > I have a question here though. How do things like MAC address > get restored? > > What about the rx mode? > > vlans? The function as is releases and reinitializes only ring state. Device configuration such as mac and vlan persist across the reset. > Also, it seems that LINK_ANNOUNCE requests will get ignored > even if they got set before the reset, leading to downtime. Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE requests? That flag is tested and netdev_notify_peers called before resetting virtio ring state.

...3); > } > > So device seems to lose all state, you have to re-program it. Oh, indeed! The guest does not reset its state, so it might be out of sync with the host after the operation. Was this not an issue when previously resetting in the context of xdp? >> > Also, it seems that LINK_ANNOUNCE requests will get ignored >> > even if they got set before the reset, leading to downtime. >> >> Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE >> requests? That flag is tested and netdev_notify_peers >> called before resetting virtio ring state. > > Yes but I...

...3); > } > > So device seems to lose all state, you have to re-program it. Oh, indeed! The guest does not reset its state, so it might be out of sync with the host after the operation. Was this not an issue when previously resetting in the context of xdp? >> > Also, it seems that LINK_ANNOUNCE requests will get ignored >> > even if they got set before the reset, leading to downtime. >> >> Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE >> requests? That flag is tested and netdev_notify_peers >> called before resetting virtio ring state. > > Yes but I...

...+ return 0; + +err: + virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED); + return ret; +} + static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads) { struct scatterlist sg; @@ -2136,6 +2172,10 @@ static void virtnet_config_changed_work(struct work_struct *work) virtnet_ack_link_announce(vi); } + if (vi->vdev->config->get_status(vi->vdev) & + VIRTIO_CONFIG_S_NEEDS_RESET) + virtnet_reset(vi); + /* Ignore unknown (future) status bits */ v &= VIRTIO_NET_S_LINK_UP; @@ -2756,7 +2796,7 @@ static __maybe_unused int virtnet_freeze(struct virtio_device *vd...

...+ return 0; + +err: + virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED); + return ret; +} + static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads) { struct scatterlist sg; @@ -2136,6 +2172,10 @@ static void virtnet_config_changed_work(struct work_struct *work) virtnet_ack_link_announce(vi); } + if (vi->vdev->config->get_status(vi->vdev) & + VIRTIO_CONFIG_S_NEEDS_RESET) + virtnet_reset(vi); + /* Ignore unknown (future) status bits */ v &= VIRTIO_NET_S_LINK_UP; @@ -2756,7 +2796,7 @@ static __maybe_unused int virtnet_freeze(struct virtio_device *vd...

...memcpy(&n->mac[0], &n->nic->conf->macaddr, sizeof(n->mac)); qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac); memset(n->vlans, 0, MAX_VLAN >> 3); } So device seems to lose all state, you have to re-program it. > > Also, it seems that LINK_ANNOUNCE requests will get ignored > > even if they got set before the reset, leading to downtime. > > Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE > requests? That flag is tested and netdev_notify_peers > called before resetting virtio ring state. Yes but I wonder if there's a rac...

...o re-program it. > > Oh, indeed! The guest does not reset its state, so it might > be out of sync with the host after the operation. Was this not > an issue when previously resetting in the context of xdp? I suspect it was broken back then, too. > >> > Also, it seems that LINK_ANNOUNCE requests will get ignored > >> > even if they got set before the reset, leading to downtime. > >> > >> Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE > >> requests? That flag is tested and netdev_notify_peers > >> called before resetting virtio ring s...

...IG_S_FAILED); > + return ret; > +} > + > static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads) > { > struct scatterlist sg; I have a question here though. How do things like MAC address get restored? What about the rx mode? vlans? Also, it seems that LINK_ANNOUNCE requests will get ignored even if they got set before the reset, leading to downtime. > @@ -2136,6 +2172,10 @@ static void virtnet_config_changed_work(struct work_struct *work) > virtnet_ack_link_announce(vi); > } > > + if (vi->vdev->config->get_status(vi->vdev) &...

...is all programmable through virtnet_set_rx_mode, virtnet_vlan_rx_add_vid, etc. But it's a lot more complex than just restoring virtnet_reset. Will need to be careful about concurrency issues at the least. Similar to the ones you point out below. > >> >> > Also, it seems that LINK_ANNOUNCE requests will get ignored >> >> > even if they got set before the reset, leading to downtime. >> >> >> >> Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE >> >> requests? That flag is tested and netdev_notify_peers >> >> called before res...

...is all programmable through virtnet_set_rx_mode, virtnet_vlan_rx_add_vid, etc. But it's a lot more complex than just restoring virtnet_reset. Will need to be careful about concurrency issues at the least. Similar to the ones you point out below. > >> >> > Also, it seems that LINK_ANNOUNCE requests will get ignored >> >> > even if they got set before the reset, leading to downtime. >> >> >> >> Do you mean act on VIRTIO_NET_F_GUEST_ANNOUNCE >> >> requests? That flag is tested and netdev_notify_peers >> >> called before res...

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA: