search for: max_vlan

...gt;mac_table.uni_overflow = 0; > memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); > 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. 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 s...

...gt;mac_table.uni_overflow = 0; > memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); > 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. 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 s...

...gt; > memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); >> > 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. >> >> 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 previou...

...gt; > memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); >> > 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. >> >> 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 previou...

...macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); > > > > > 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. > > > > Oh, indeed! The guest does not reset its state, so it might > > > > be out of sync with the host after the operati...

>> +static int virtnet_reset(struct virtnet_info *vi) >> +{ >> + struct virtio_device *dev = vi->vdev; >> + int ret; >> + >> + virtio_config_disable(dev); >> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED; >> + virtnet_freeze_down(dev, true); >> + remove_vq_common(vi); >> +

>> +static int virtnet_reset(struct virtnet_info *vi) >> +{ >> + struct virtio_device *dev = vi->vdev; >> + int ret; >> + >> + virtio_config_disable(dev); >> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED; >> + virtnet_freeze_down(dev, true); >> + remove_vq_common(vi); >> +

...o_net_set_features(VirtIODevice *vdev, uint32_t features) vhost_net_ack_features(get_vhost_net(nc->peer), features); } - if ((1 << VIRTIO_NET_F_CTRL_VLAN) & features) { + if (__virtio_has_feature(features, VIRTIO_NET_F_CTRL_VLAN)) { memset(n->vlans, 0, MAX_VLAN >> 3); } else { memset(n->vlans, 0xff, MAX_VLAN >> 3); @@ -585,7 +588,7 @@ static int virtio_net_handle_offloads(VirtIONet *n, uint8_t cmd, uint64_t offloads; size_t s; - if (!((1 << VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) & vdev->guest_features))...

...o_net_set_features(VirtIODevice *vdev, uint32_t features) vhost_net_ack_features(get_vhost_net(nc->peer), features); } - if ((1 << VIRTIO_NET_F_CTRL_VLAN) & features) { + if (__virtio_has_feature(features, VIRTIO_NET_F_CTRL_VLAN)) { memset(n->vlans, 0, MAX_VLAN >> 3); } else { memset(n->vlans, 0xff, MAX_VLAN >> 3); @@ -585,7 +588,7 @@ static int virtio_net_handle_offloads(VirtIONet *n, uint8_t cmd, uint64_t offloads; size_t s; - if (!((1 << VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) & vdev->guest_features))...

...verflow = 0; n->mac_table.uni_overflow = 0; memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); 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 f...

...memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); >>>> 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. >>> 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...

...rflow = 0; > > memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); > > 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. > > 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 contex...

..._TABLE_ENTRIES * ETH_ALEN); >> > > > > 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. >> > > > Oh, indeed! The guest does not reset its state, so it might >> > > > be out of sync with the hos...

...-) diff --git a/hw/virtio-net.c b/hw/virtio-net.c index c8dabbe..4a82348 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -709,7 +709,10 @@ VirtIODevice *virtio_net_init(DeviceState *dev) n->mac_table.macs = qemu_mallocz(MAC_TABLE_ENTRIES * ETH_ALEN); n->vlans = qemu_mallocz(MAX_VLAN >> 3); - n->vdev.nvectors = 3; + if (dev->nd->nvectors == NIC_NVECTORS_UNSPECIFIED) + n->vdev.nvectors = 3; + else + n->vdev.nvectors = dev->nd->nvectors; register_savevm("virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,...

...-) diff --git a/hw/virtio-net.c b/hw/virtio-net.c index c8dabbe..4a82348 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -709,7 +709,10 @@ VirtIODevice *virtio_net_init(DeviceState *dev) n->mac_table.macs = qemu_mallocz(MAC_TABLE_ENTRIES * ETH_ALEN); n->vlans = qemu_mallocz(MAX_VLAN >> 3); - n->vdev.nvectors = 3; + if (dev->nd->nvectors == NIC_NVECTORS_UNSPECIFIED) + n->vdev.nvectors = 3; + else + n->vdev.nvectors = dev->nd->nvectors; register_savevm("virtio-net", virtio_net_id++, VIRTIO_NET_VM_VERSION,...

Currently virtio-net code relys on the layout of descriptor, this patchset removed the assumptions and introduced a control command to set mac address. Last patch is a trivial renaming. V2: check guest's iov_len V3: fix of migration compatibility make mac field in config space read-only when new feature is acked V4: add fix of descriptor layout assumptions, trivial rename V5: fix

Currently virtio-net code relys on the layout of descriptor, this patchset removed the assumptions and introduced a control command to set mac address. Last patch is a trivial renaming. V2: check guest's iov_len V3: fix of migration compatibility make mac field in config space read-only when new feature is acked V4: add fix of descriptor layout assumptions, trivial rename V5: fix

From: Dmitry Fleytman <dfleytma at redhat.com> One of recently introduced Windows features (RSC) requires network driver to be able to enable and disable HW LRO offload on the fly without device reinitialization. Current Virtio specification doesn't support this requirement. The solution proposed by following spec patch is to add a new control command for this purpose. The same

From: Dmitry Fleytman <dfleytma at redhat.com> One of recently introduced Windows features (RSC) requires network driver to be able to enable and disable HW LRO offload on the fly without device reinitialization. Current Virtio specification doesn't support this requirement. The solution proposed by following spec patch is to add a new control command for this purpose. The same

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to