search for: virtio_net_ctrl_mac_addr_set

...\begin_layout Standard @@ -5324,6 +5337,17 @@ struct virtio_net_ctrl_mac { \begin_layout Plain Layout #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0 +\change_inserted -1930653948 1358318313 + +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1930653948 1358318331 + + #define VIRTIO_NET_CTRL_MAC_ADDR_SET 1 +\change_unchanged + \end_layout \end_inset @@ -5349,6 +5373,25 @@ T_CTRL_MAC_TABLE_SET. The command-specific-data is two variable length tables of 6-byte MAC addresses. The first table contains unicast addresses, and the second contains multicast addresses. +\change_inserted -1...

...\begin_layout Standard @@ -5324,6 +5337,17 @@ struct virtio_net_ctrl_mac { \begin_layout Plain Layout #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0 +\change_inserted -1930653948 1358318313 + +\end_layout + +\begin_layout Plain Layout + +\change_inserted -1930653948 1358318331 + + #define VIRTIO_NET_CTRL_MAC_ADDR_SET 1 +\change_unchanged + \end_layout \end_inset @@ -5349,6 +5373,25 @@ T_CTRL_MAC_TABLE_SET. The command-specific-data is two variable length tables of 6-byte MAC addresses. The first table contains unicast addresses, and the second contains multicast addresses. +\change_inserted -1...

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. V2: check return of sending command, delay eth_mac_addr() Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. V2: check return of sending command, delay eth_mac_addr() Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new

...re >> synchronization between the hypervisor and the PF/VF drivers. Most of the VF drivers >> don't allow changing guest MAC unless it is a trusted VF. > > OK but it's a policy thing. Maybe it's a trusted VF. Who knows? > For example I can see host just > failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it. > I'm not sure why VIRTIO_NET_F_STANDBY has to block it in the guest. That's why I think pairing using MAC is fragile IMHO. When VF's MAC got changed before virtio attempts to match and pair the device, it ends up with no pairing found out at all. UUID is be...

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new control to set macaddr drivers/net/virtio_net.c |

From: Amos Kong <akong at redhat.com> Currenly mac is programmed byte by byte. This means that we have an intermediate step where mac is wrong. Second patch introduced a new vq control command to set mac address in one time. Amos Kong (2): move virtnet_send_command() above virtnet_set_mac_address() virtio-net: introduce a new control to set macaddr drivers/net/virtio_net.c |

...t; > synchronization between the hypervisor and the PF/VF drivers. Most of the VF drivers > > don't allow changing guest MAC unless it is a trusted VF. > > OK but it's a policy thing. Maybe it's a trusted VF. Who knows? > For example I can see host just > failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it. > I'm not sure why VIRTIO_NET_F_STANDBY has to block it in the guest. > So, what I get from this is that QEMU needs to be able to control all of standby, uuid, and mac to accommodate the different setups (respectively have libvirt/management software set it up)....

...eth_prepare_mac_addr_change(dev, addr); if (ret) - return ret; + goto out; if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) { sg_init_one(&sg, addr->sa_data, dev->addr_len); @@ -982,7 +987,8 @@ static int virtnet_set_mac_address(struct net_device *dev, void *p) VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) { dev_warn(&vdev->dev, "Failed to set mac address by vq command.\n"); - return -EINVAL; + ret = -EINVAL; + goto out; } } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC) && !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) { @@ -996,8 +...

...eth_prepare_mac_addr_change(dev, addr); if (ret) - return ret; + goto out; if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) { sg_init_one(&sg, addr->sa_data, dev->addr_len); @@ -982,7 +987,8 @@ static int virtnet_set_mac_address(struct net_device *dev, void *p) VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) { dev_warn(&vdev->dev, "Failed to set mac address by vq command.\n"); - return -EINVAL; + ret = -EINVAL; + goto out; } } else if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC) && !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) { @@ -996,8 +...

...visor and the PF/VF drivers. Most of the VF drivers >> >> don't allow changing guest MAC unless it is a trusted VF. >> > >> > OK but it's a policy thing. Maybe it's a trusted VF. Who knows? >> > For example I can see host just >> > failing VIRTIO_NET_CTRL_MAC_ADDR_SET if it wants to block it. >> > I'm not sure why VIRTIO_NET_F_STANDBY has to block it in the guest. >> >> That's why I think pairing using MAC is fragile IMHO. When VF's MAC >> got changed before virtio attempts to match and pair the device, it >> ends up...

On 6/22/2018 5:17 PM, Siwei Liu wrote: > On Fri, Jun 22, 2018 at 4:40 PM, Siwei Liu <loseweigh at gmail.com> wrote: >> On Fri, Jun 22, 2018 at 3:25 PM, Michael S. Tsirkin <mst at redhat.com> wrote: >>> On Fri, Jun 22, 2018 at 02:51:11PM -0700, Siwei Liu wrote: >>>> On Fri, Jun 22, 2018 at 2:29 PM, Michael S. Tsirkin <mst at redhat.com> wrote:

...kick(vi->cvq))) return status == VIRTIO_NET_OK; @@ -934,8 +930,7 @@ static int virtnet_set_mac_address(struc if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) { sg_init_one(&sg, addr->sa_data, dev->addr_len); if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC, - VIRTIO_NET_CTRL_MAC_ADDR_SET, - &sg, NULL)) { + VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) { dev_warn(&vdev->dev, "Failed to set mac address by vq command.\n"); return -EINVAL; @@ -1008,7 +1003,7 @@ static void virtnet_ack_link_announce(st { rtnl_lock(); if (!virtnet_send_comman...

...work fine without getting MAC explicitly. > > OK > > > > > > + struct scatterlist sg; > > > + > > > + sg_init_one(&sg, dev->dev_addr, dev->addr_len); > > > + if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC, > > > + VIRTIO_NET_CTRL_MAC_ADDR_SET, &sg)) { > > > + dev_warn(&vdev->dev, "Failed to update MAC address.\n"); > > > > Here, I'm not sure we want to proceed. Is it useful sometimes? > > I think reporting an error is always useful, but I can remove that if you prefer. No the ques...

...00644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -5430,7 +5430,7 @@ T_CTRL_MAC_TABLE_SET. \begin_layout Standard -\change_inserted -1930653948 1358506710 +\change_inserted -1930653948 1363832689 The config space \begin_inset Quotes eld \end_inset @@ -5464,6 +5464,15 @@ mac Therefore, VIRTIO_NET_CTRL_MAC_ADDR_SET is preferred, especially while the NIC is up. The command-specific-data is a 6-byte MAC address. +\end_layout + +\begin_layout Standard + +\change_inserted -1930653948 1363833477 +The legacy guests don't support the new command, they still change MAC address + in original way, that's no...

...00644 --- a/virtio-spec.lyx +++ b/virtio-spec.lyx @@ -5430,7 +5430,7 @@ T_CTRL_MAC_TABLE_SET. \begin_layout Standard -\change_inserted -1930653948 1358506710 +\change_inserted -1930653948 1363832689 The config space \begin_inset Quotes eld \end_inset @@ -5464,6 +5464,15 @@ mac Therefore, VIRTIO_NET_CTRL_MAC_ADDR_SET is preferred, especially while the NIC is up. The command-specific-data is a 6-byte MAC address. +\end_layout + +\begin_layout Standard + +\change_inserted -1930653948 1363833477 +The legacy guests don't support the new command, they still change MAC address + in original way, that's no...

...ables of the device are not updated and this can block the communication between two namespaces. To fix this problem, use virtnet_send_command(VIRTIO_NET_CTRL_MAC) to set the address from virtnet_probe() when the MAC address is not provided by the device. v3: - update comments - fail probe if VIRTIO_NET_CTRL_MAC_ADDR_SET fails - move the virtnet_send_command() upper, inside the RTNL lock, this simplifies the cleanup in case of error, and a future patch from Jason adds an ASSERT_RTNL() in virtnet_send_command() ("virtio-net: convert rx mode setting to use workqueue") - add a patch to disabl...

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

....mac, n->mac, ETH_ALEN)) { memcpy(n->mac, netcfg.mac, ETH_ALEN); qemu_format_nic_info_str(&n->nic->nc, n->mac); } @@ -349,6 +350,13 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t cmd, { struct virtio_net_ctrl_mac mac_data; + if (cmd == VIRTIO_NET_CTRL_MAC_ADDR_SET && elem->out_num == 2 && + elem->out_sg[1].iov_len == ETH_ALEN) { + memcpy(n->mac, elem->out_sg[1].iov_base, elem->out_sg[1].iov_len); + qemu_format_nic_info_str(&n->nic->nc, n->mac); + return VIRTIO_NET_OK; + } + if (c...