From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Cc: virtualization@lists.linux-foundation.org,
virtio-dev@lists.oasis-open.org, jesse.brandeburg@intel.com,
alexander.h.duyck@intel.com, jasowang@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
Date: Tue, 5 Jun 2018 23:37:54 +0300 [thread overview]
Message-ID: <20180605232907-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <0a69d897-d084-8a7e-a681-86a49ab8f59a@intel.com>
On Tue, Jun 05, 2018 at 01:20:33PM -0700, Samudrala, Sridhar wrote:
>
> On 6/5/2018 5:33 AM, Michael S. Tsirkin wrote:
> > I don't think this is sufficient.
>
> Sure. This is not sufficient for a complete solution, but is Qemu the right place
> to manage primary/standby interfaces?
>
> I think the other steps including plugging/unplugging the primary interface needs
> to handled by some orchestration layer.
I don't see any real benefit to it but yes, you can push it up the stack.
Unfortunately the patch still won't be sufficient then, see below :)
>
> >
> > 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.
>
> Yes. Isn't this possible today when a VM is started with a mis-configured domain
> XML file that passes a virtio-net interface and a VF with the same MAC?
Yes, so if you misconfigure the hypervisor then your guest won't run.
Not sure what you are trying to say by this though.
>
> >
> > I think that we should only make primary visible after guest acked the
> > backup feature bit.
>
> The primary can be plugged/unplugged at any time by the management layer.
> So i guess this needs to be handled in the libvirt layer.
management just wants to give the primary to guest and later take it back,
it really does not care about the details of the process,
so I don't see what does pushing it up the stack buy you.
So I don't think it *needs* to be done in libvirt. It probably can if you
add a bunch of hooks so it knows whenever vm reboots, driver binds and
unbinds from device, and can check that backup flag was set.
If you are pushing for a setup like that please get a buy-in
from libvirt maintainers or better write a patch.
> >
> > And on reset or when backup is cleared in some other way, unplug the
> > primary.
> >
> > Something like the below will do the job:
> >
> > Primary device is added with a special "primary-failover" flag.
>
> Are you suggesting an extension to Qemu to add another flag for
> primary device too?
Exactly.
> > A virtual machine is then initialized with just a standby virtio
> > device. Primary is not yet added.
> >
> > Later QEMU detects that guest driver device set DRIVER_OK.
> > It then exposes the primary device to the guest, and triggers
> > a device addition event (hot-plug event) for it.
> >
> > If QEMU detects guest driver removal, it initiates a hot-unplug sequence
> > to remove the primary driver. In particular, if QEMU detects guest
> > re-initialization (e.g. by detecting guest reset) it immediately removes
> > the primary device.
> >
> > We can move some of this code to management as well, architecturally it
> > does not make too much sense but it might be easier implementation-wise.
> >
> > HTH
> >
> > On Mon, Jun 04, 2018 at 06:41:48PM -0700, 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 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: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > > > ---
> > > > hw/net/virtio-net.c | 2 ++
> > > > include/standard-headers/linux/virtio_net.h | 3 +++
> > > > 2 files changed, 5 insertions(+)
> > > >
> > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > > index 90502fca7c..38b3140670 100644
> > > > --- a/hw/net/virtio-net.c
> > > > +++ b/hw/net/virtio-net.c
> > > > @@ -2198,6 +2198,8 @@ static 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/virtio_net.h
> > > > @@ -57,6 +57,9 @@
> > > > * Steering */
> > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > > > +#define VIRTIO_NET_F_STANDBY 62 /* Act as standby for another device
> > > > + * with the same MAC.
> > > > + */
> > > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> > > > #ifndef VIRTIO_NET_NO_LEGACY
next prev parent reply other threads:[~2018-06-05 20:38 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 23:09 [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net Sridhar Samudrala
2018-06-05 1:41 ` Samudrala, Sridhar
2018-06-05 2:06 ` Jason Wang
2018-06-06 18:17 ` Samudrala, Sridhar
2018-06-06 18:52 ` [Qemu-devel] [libvirt] " Ján Tomko
2018-06-06 19:39 ` Samudrala, Sridhar
2018-06-06 18:53 ` [Qemu-devel] " Michael S. Tsirkin
2018-06-05 12:33 ` Michael S. Tsirkin
2018-06-05 20:20 ` Samudrala, Sridhar
2018-06-05 20:37 ` Michael S. Tsirkin [this message]
2018-06-05 21:16 ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-06-05 21:32 ` Michael S. Tsirkin
2018-06-05 22:09 ` Siwei Liu
2018-06-12 11:47 ` Michael S. Tsirkin
2018-06-14 0:56 ` Siwei Liu
2018-06-06 2:29 ` [Qemu-devel] " Jason Wang
2018-06-12 11:54 ` Michael S. Tsirkin
2018-06-13 0:20 ` Samudrala, Sridhar
2018-06-13 2:41 ` Jason Wang
2018-06-13 2:38 ` Jason Wang
2018-06-13 4:24 ` Samudrala, Sridhar
2018-06-13 5:40 ` Jason Wang
2018-06-21 18:14 ` Michael S. Tsirkin
2018-06-22 1:07 ` [Qemu-devel] [virtio-dev] " Siwei Liu
2018-06-22 2:30 ` Michael S. Tsirkin
2018-06-22 19:43 ` Siwei Liu
2018-06-22 21:47 ` Michael S. Tsirkin
2018-06-22 22:25 ` Siwei Liu
2018-06-22 22:28 ` Michael S. Tsirkin
2018-06-11 17:26 ` [Qemu-devel] " Michael S. Tsirkin
2018-06-12 1:54 ` Jason Wang
2018-06-12 2:17 ` Michael S. Tsirkin
2018-06-12 5:02 ` Samudrala, Sridhar
2018-06-12 11:34 ` Michael S. Tsirkin
2018-06-13 0:08 ` [Qemu-devel] [virtio-dev] " Samudrala, Sridhar
2018-06-14 1:02 ` Siwei Liu
2018-06-14 10:02 ` Cornelia Huck
2018-06-15 1:57 ` Siwei Liu
2018-06-15 11:48 ` Cornelia Huck
2018-06-15 17:06 ` Siwei Liu
2018-06-19 10:54 ` Cornelia Huck
2018-06-19 20:09 ` Siwei Liu
2018-06-20 14:34 ` Cornelia Huck
2018-06-20 19:59 ` Siwei Liu
2018-06-19 20:32 ` Michael S. Tsirkin
2018-06-20 9:53 ` Cornelia Huck
2018-06-20 14:11 ` Michael S. Tsirkin
2018-06-20 16:06 ` Cornelia Huck
2018-06-20 19:48 ` Michael S. Tsirkin
2018-06-21 14:59 ` Cornelia Huck
2018-06-21 18:20 ` Michael S. Tsirkin
2018-06-22 15:09 ` Cornelia Huck
2018-06-22 19:05 ` Michael S. Tsirkin
2018-06-22 20:21 ` Siwei Liu
2018-06-22 21:32 ` Michael S. Tsirkin
2018-06-22 21:57 ` Siwei Liu
2018-06-22 22:33 ` Michael S. Tsirkin
2018-06-23 0:05 ` Siwei Liu
2018-06-26 15:08 ` Cornelia Huck
2018-06-26 17:50 ` Michael S. Tsirkin
2018-06-27 9:11 ` Cornelia Huck
2018-06-25 9:55 ` Cornelia Huck
2018-06-26 1:46 ` Michael S. Tsirkin
2018-06-26 11:55 ` Cornelia Huck
2018-06-26 13:54 ` Michael S. Tsirkin
2018-06-22 21:43 ` Michael S. Tsirkin
2018-06-27 10:10 ` Cornelia Huck
2018-06-22 1:21 ` Siwei Liu
2018-06-22 2:25 ` Venu Busireddy
2018-06-22 2:32 ` Michael S. Tsirkin
2018-06-22 20:00 ` Siwei Liu
2018-06-22 20:03 ` Siwei Liu
2018-06-22 21:29 ` Michael S. Tsirkin
2018-06-22 21:51 ` Siwei Liu
2018-06-22 22:25 ` Michael S. Tsirkin
2018-06-22 23:40 ` Siwei Liu
2018-06-23 0:17 ` Siwei Liu
2018-06-24 1:45 ` Michael S. Tsirkin
2018-06-25 17:54 ` Samudrala, Sridhar
2018-06-26 1:50 ` Michael S. Tsirkin
2018-06-26 15:17 ` Cornelia Huck
2018-06-26 15:38 ` Michael S. Tsirkin
2018-06-26 16:03 ` Cornelia Huck
2018-06-26 17:42 ` Michael S. Tsirkin
2018-06-26 23:38 ` Siwei Liu
2018-06-27 0:29 ` Michael S. Tsirkin
2018-06-27 6:21 ` Siwei Liu
2018-06-27 6:49 ` Samudrala, Sridhar
2018-06-27 7:03 ` Siwei Liu
2018-06-15 2:34 ` Michael S. Tsirkin
2018-06-15 9:32 ` Cornelia Huck
2018-06-15 12:31 ` Michael S. Tsirkin
2018-06-18 13:27 ` Cornelia Huck
2018-06-14 12:50 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180605232907-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.h.duyck@intel.com \
--cc=jasowang@redhat.com \
--cc=jesse.brandeburg@intel.com \
--cc=qemu-devel@nongnu.org \
--cc=sridhar.samudrala@intel.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).