similar to: [PATCH v4 0/3] virtio_net: allow hypervisor to indicate linkspeed and duplex setting

We have found it useful to be able to set the linkspeed and duplex settings from the host-side for virtio_net. This obviates the need for guest changes and settings for these fields, and does not require custom ethtool commands for virtio_net. The ability to set linkspeed and duplex is useful in various cases as described here: 16032be virtio_net: add ethtool support for set and get of settings

In prepartion for using some of the high order feature bits, make sure that virtio-net uses 64-bit values everywhere. Signed-off-by: Jason Baron <jbaron at akamai.com> Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> --- hw/net/virtio-net.c | 54 +++++++++++++++++++++--------------------- include/hw/virtio/virtio-net.h |

We have found it useful to be able to set the linkspeed and duplex settings from the host-side for virtio_net. This obviates the need for guest changes and settings for these fields, and does not require custom ethtool commands for virtio_net. The ability to set linkspeed and

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. I tested this with a small change to the patch to mark the STANDBY feature 'true' by default as i am using libvirt to start the VMs. Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt XML file? Signed-off-by:

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. I tested this with a small change to the patch to mark the STANDBY feature 'true' by default as i am using libvirt to start the VMs. Is there a way to pass the newly added feature bit 'standby' to qemu via libvirt XML file? Signed-off-by:

I don't think this is sufficient. If both primary and standby devices are present, a legacy guest without support for the feature might see two devices with same mac and get confused. I think that we should only make primary visible after guest acked the backup feature bit. And on reset or when backup is cleared in some other way, unplug the primary. Something like the below will do the

I don't think this is sufficient. If both primary and standby devices are present, a legacy guest without support for the feature might see two devices with same mac and get confused. I think that we should only make primary visible after guest acked the backup feature bit. And on reset or when backup is cleared in some other way, unplug the primary. Something like the below will do the

On 2018?06?12? 01:26, Michael S. Tsirkin wrote: > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote: >> 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. >> >> I tested this with a small change to the patch to mark the STANDBY feature 'true' >> by

On 2018?06?12? 01:26, Michael S. Tsirkin wrote: > On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote: >> 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. >> >> I tested this with a small change to the patch to mark the STANDBY feature 'true' >> by

On 2018?06?05? 09:41, Samudrala, Sridhar wrote: > Ping on this patch now that the kernel patches are accepted into > davem's net-next tree. > https://patchwork.ozlabs.org/cover/920005/ > > > On 5/7/2018 4:09 PM, Sridhar Samudrala wrote: >> This feature bit can be used by hypervisor to indicate virtio_net >> device to >> act as a standby for another device

On 2018?06?05? 09:41, Samudrala, Sridhar wrote: > Ping on this patch now that the kernel patches are accepted into > davem's net-next tree. > https://patchwork.ozlabs.org/cover/920005/ > > > On 5/7/2018 4:09 PM, Sridhar Samudrala wrote: >> This feature bit can be used by hypervisor to indicate virtio_net >> device to >> act as a standby for another device

On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote: > On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote: >> >> On 2018?06?12? 01:26, Michael S. Tsirkin wrote: >>> On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote: >>>> This feature bit can be used by hypervisor to indicate virtio_net device to >>>> act as a standby for another

On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote: > On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote: >> >> On 2018?06?12? 01:26, Michael S. Tsirkin wrote: >>> On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote: >>>> This feature bit can be used by hypervisor to indicate virtio_net device to >>>> act as a standby for another

On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: > > > On 2018?06?05? 20:33, Michael S. Tsirkin wrote: > > I don't think this is sufficient. > > > > If both primary and standby devices are present, a legacy guest without > > support for the feature might see two devices with same mac and get > > confused. > > > > I think that we

On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: > > > On 2018?06?05? 20:33, Michael S. Tsirkin wrote: > > I don't think this is sufficient. > > > > If both primary and standby devices are present, a legacy guest without > > support for the feature might see two devices with same mac and get > > confused. > > > > I think that we

On 6/12/2018 7:38 PM, Jason Wang wrote: > > > On 2018?06?12? 19:54, Michael S. Tsirkin wrote: >> On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: >>> >>> On 2018?06?05? 20:33, Michael S. Tsirkin wrote: >>>> I don't think this is sufficient. >>>> >>>> If both primary and standby devices are present, a legacy guest

On 6/12/2018 7:38 PM, Jason Wang wrote: > > > On 2018?06?12? 19:54, Michael S. Tsirkin wrote: >> On Wed, Jun 06, 2018 at 10:29:03AM +0800, Jason Wang wrote: >>> >>> On 2018?06?05? 20:33, Michael S. Tsirkin wrote: >>>> I don't think this is sufficient. >>>> >>>> If both primary and standby devices are present, a legacy guest

Another iteration of virtio-1 patches for qemu, as always available on git://github.com/cohuck/qemu virtio-1 This one seems to work together with the current vhost-next patches (well, I can ping :) Changes from v4: - add helpers for feature bit manipulation and checking - use 64 bit feature bits instead of 32 bit arrays - infrastructure to allow devices to offer different sets of feature bits

Another iteration of virtio-1 patches for qemu, as always available on git://github.com/cohuck/qemu virtio-1 This one seems to work together with the current vhost-next patches (well, I can ping :) Changes from v4: - add helpers for feature bit manipulation and checking - use 64 bit feature bits instead of 32 bit arrays - infrastructure to allow devices to offer different sets of feature bits

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