search for: virtio_net_f_standby

...c Property virtio_net_properties[] = { true), DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, + false), DEFINE_PROP_END_OF_LIST(), }; diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h index e9f255ea3f..01ec09684c 100644 --- a/include/standard-headers/linux/virtio_net.h +++ b/include/standard-headers/linux/vir...

...c Property virtio_net_properties[] = { true), DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, + false), DEFINE_PROP_END_OF_LIST(), }; diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h index e9f255ea3f..01ec09684c 100644 --- a/include/standard-headers/linux/virtio_net.h +++ b/include/standard-headers/linux/vir...

This feature bit can be used by hypervisor to indicate virtio_net device to act as a standby for another device with the same MAC address. VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit. Signed-off-by: Sridhar Samudrala <sridhar.samudrala at intel.com> --- drivers/net/virtio_net.c | 2 +- include/uapi/linux/virtio_net.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b...

...roperties[] = { > true), > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, > + false), > DEFINE_PROP_END_OF_LIST(), > }; > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h > index e9f255ea3f..01ec09684c 100644 > --- a/include/standard-headers/linux/virtio_net.h &g...

...t_properties[] = { > true), > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, > + false), > DEFINE_PROP_END_OF_LIST(), > }; > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h > index e9f255ea3f..01ec09684c 100644 > --- a/include/standard-headers/linux/virtio_net.h >...

...true), > > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), > > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, > > > + false), > > > DEFINE_PROP_END_OF_LIST(), > > > }; > > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h > > > index e9f255ea3f..01ec09684c 100644 > > >...

...>> true), >> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), >> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), >> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, >> + false), >> DEFINE_PROP_END_OF_LIST(), >> }; >> >> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h >> index e9f255ea3f..01ec09684c 100644 >> --- a/include/standard-h...

...>> true), >> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), >> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), >> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, >> + false), >> DEFINE_PROP_END_OF_LIST(), >> }; >> >> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h >> index e9f255ea3f..01ec09684c 100644 >> --- a/include/standard-h...

...gt;>> ????? DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, >>> SPEED_UNKNOWN), >>> ????? DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), >>> +??? DEFINE_PROP_BIT64("standby", VirtIONet, host_features, >>> VIRTIO_NET_F_STANDBY, >>> +????????????????????? false), >>> ????? DEFINE_PROP_END_OF_LIST(), >>> ? }; >>> ? diff --git a/include/standard-headers/linux/virtio_net.h >>> b/include/standard-headers/linux/virtio_net.h >>> index e9f255ea3f..01ec09684c 100644 >>&...

...true), >>> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), >>> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), >>> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, >>> + false), >>> DEFINE_PROP_END_OF_LIST(), >>> }; >>> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h >>> index e9f255ea3f..01ec09684c 100644 >>> --- a/incl...

...true), >>> DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), >>> DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), >>> + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, >>> + false), >>> DEFINE_PROP_END_OF_LIST(), >>> }; >>> diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h >>> index e9f255ea3f..01ec09684c 100644 >>> --- a/incl...

...f 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 better. -Siwei > > -- > MST

...nd 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. -- MST

...n'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). Is the host > able to find out respectively...

...t 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). Is the host > &g...

...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. Guest seems to match on the hardware mac and ignore whatever...

...e 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). Is the host able to find out respectively define whether a VF is truste...

...gt; > > DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN), > > > > > DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str), > > > > > + DEFINE_PROP_BIT64("standby", VirtIONet, host_features, VIRTIO_NET_F_STANDBY, > > > > > + false), > > > > > DEFINE_PROP_END_OF_LIST(), > > > > > }; > > > > > diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h > > > > >...

...hanging 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. >> Guest seems to match on the hardwar...

...different containers). >> >> >> >> But it is also handy for when you assign a PF, since then you >> >> can't set the MAC. >> >> >> > >> > OK, so what about the following: >> > >> > - introduce a new feature bit, VIRTIO_NET_F_STANDBY_UUID that indicates >> > that we have a new uuid field in the virtio-net config space >> > - in QEMU, add a property for virtio-net that allows to specify a uuid, >> > offer VIRTIO_NET_F_STANDBY_UUID if set >> > - when configuring, set the property to the gro...