On 4/30/2018 12:03 AM, Jiri Pirko wrote:
Mon, Apr 30, 2018 at 04:47:03AM CEST, sridhar.samudrala@xxxxxxxxx wrote:
On 4/28/2018 12:50 AM, Jiri Pirko wrote:
Fri, Apr 27, 2018 at 07:06:57PM CEST,sridhar.samudrala@xxxxxxxxx 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.
VIRTIO_NET_F_STANDBY is defined as bit 62 as it is a device feature bit.
Signed-off-by: Sridhar Samudrala<sridhar.samudrala@xxxxxxxxx>
---
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/drivers/net/virtio_net.c
index 3b5991734118..51a085b1a242 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2999,7 +2999,7 @@ static struct virtio_device_id id_table[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
VIRTIO_NET_F_CTRL_MAC_ADDR, \
VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
- VIRTIO_NET_F_SPEED_DUPLEX
+ VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY
This is not part of current qemu master (head 6f0c4706b35dead265509115ddbd2a8d1af516c1)
Were I can find the qemu code?
Also, I think it makes sense to push HW (qemu HW in this case) first
and only then the driver.
I had sent qemu patch with a couple of earlier versions of this patchset.
Will include it when i send out v10.
The point was, don't you want to push it to qemu first? Did you at least
send RFC to qemu?
Yes. Here is the link to the RFC patch.
https://patchwork.ozlabs.org/patch/859521/
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
