similar to: [PATCH v3 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

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

And yet another iteration of virtio-1 support in qemu, tested with the latest virtio kernel patches. Find it at git://github.com/cohuck/qemu virtio-1 Changes from v5: - fixed stupid bug in "virtio: support more feature bits": we need to define a proper prop backend for 64 bit wide handling... - don't negotiate revision 1 unless VERSION_1 is offered - use 64 bit wide features