search for: _f_standby

...t; >>> >> 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 pro...

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

...t; >> then with 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 group UUID of the v...

On Tue, Jun 05, 2018 at 02:16:44PM -0700, Siwei Liu wrote: > Good to see this discussion going. I share the same feeling that the > decision of plugging the primary (passthrough) should only be made > until guest driver acknowledges DRIVER_OK and _F_STANDBY. > Architecturally this intelligence should be baken to QEMU itself > rather than moving up to management stack, such as libvirt. > > A few questions in line below. > > On Tue, Jun 5, 2018 at 5:33 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > I don't thin...

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

...t 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 conf...

...ou > >> >>> >> 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 > &g...

...;>> >> 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...

Good to see this discussion going. I share the same feeling that the decision of plugging the primary (passthrough) should only be made until guest driver acknowledges DRIVER_OK and _F_STANDBY. Architecturally this intelligence should be baken to QEMU itself rather than moving up to management stack, such as libvirt. A few questions in line below. On Tue, Jun 5, 2018 at 5:33 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > I don't think this is sufficient. > > If...

...an'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_STA...

...t at redhat.com> wrote: > On Tue, Jun 05, 2018 at 02:16:44PM -0700, Siwei Liu wrote: >> Good to see this discussion going. I share the same feeling that the >> decision of plugging the primary (passthrough) should only be made >> until guest driver acknowledges DRIVER_OK and _F_STANDBY. >> Architecturally this intelligence should be baken to QEMU itself >> rather than moving up to management stack, such as libvirt. >> >> A few questions in line below. >> >> On Tue, Jun 5, 2018 at 5:33 AM, Michael S. Tsirkin <mst at redhat.com> wrote: >...

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

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