qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sameeh Jubran <sameeh@daynix.com>
Cc: qemu-devel@nongnu.org, Jason Wang <jasowang@redhat.com>,
	Yan Vugenfirer <yan@daynix.com>,
	Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/2] Attempt to implement the standby feature for assigned network devices
Date: Thu, 25 Oct 2018 18:17:43 -0400	[thread overview]
Message-ID: <20181025181643-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20181025140631.634922-1-sameeh@daynix.com>

On Thu, Oct 25, 2018 at 05:06:29PM +0300, Sameeh Jubran wrote:
> From: Sameeh Jubran <sjubran@redhat.com>
> 
> Hi all,
> 
> Background:
> 
> There has been a few attempts to implement the standby feature for vfio
> assigned devices which aims to enable the migration of such devices. This
> is another attempt.
> 
> The series implements an infrastructure for hiding devices from the bus
> upon boot. What it does is the following:
> 
> * In the first patch the infrastructure for hiding the device is added
>   for the qbus and qdev APIs. A "hidden" boolean is added to the device
>   state and it is set based on a callback to the standby device which
>   registers itself for handling the assessment: "should the primary device
>   be hidden?" by cross validating the ids of the devices.
> 
> * In the second patch the virtio-net uses the API to hide the vfio
>   device and unhides it when the feature is acked.
> 
> Disclaimers:
> 
> * I have only scratch tested this and from qemu side, it seems to be
>   working.
> * This is an RFC so it lacks some proper error handling in few cases
>   and proper resource freeing. I wanted to get some feedback first
>   before it is finalized.
> 
> Command line example:
> 
> /home/sameeh/Builds/failover/qemu/x86_64-softmmu/qemu-system-x86_64 \
> -netdev tap,id=hostnet0,script=world_bridge_standalone.sh,downscript=no,ifname=cc1_71 \
> -netdev tap,vhost=on,id=hostnet1,script=world_bridge_standalone.sh,downscript=no,ifname=cc1_72,queues=4 \
> -device virtio-net,host_mtu=1500,netdev=hostnet1,id=cc1_72,vectors=10,mq=on,primary=cc1_71 \
> -device e1000,netdev=hostnet0,id=cc1_71,standby=cc1_72 \
> 
> Migration support:
> 
> Pre migration or during setup phase of the migration we should send an
> unplug request to the guest to unplug the primary device. I haven't had
> the chance to implement that part yet but should do soon. Do you know
> what's the best approach to do so? I wanted to have a callback to the
> virtio-net device which tries to send an unplug request to the guest and
> if succeeds then the migration continues. It needs to handle the case where
> the migration fails and then it has to replug the primary device back.
> 
> The following terms are used as interchangeable:
> standby - virtio-net
> primary - vfio-device - physical device - assigned device
> 
> Please share your thoughts and suggestions,
> Thanks!

Didn't have time to look at code yet. Could you test with a VF please?
That's the real test, isn't it?

> Sameeh Jubran (2):
>   qdev/qbus: Add hidden device support
>   virtio-net: Implement VIRTIO_NET_F_STANDBY feature
> 
>  hw/core/qdev.c                 | 48 +++++++++++++++++++++++++---
>  hw/net/virtio-net.c            | 25 +++++++++++++++
>  hw/pci/pci.c                   |  1 +
>  include/hw/pci/pci.h           |  2 ++
>  include/hw/qdev-core.h         | 11 ++++++-
>  include/hw/virtio/virtio-net.h |  5 +++
>  qdev-monitor.c                 | 58 ++++++++++++++++++++++++++++++++--
>  7 files changed, 142 insertions(+), 8 deletions(-)
> 
> -- 
> 2.17.0

  parent reply	other threads:[~2018-10-25 22:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25 14:06 [Qemu-devel] [RFC 0/2] Attempt to implement the standby feature for assigned network devices Sameeh Jubran
2018-10-25 14:06 ` [Qemu-devel] [RFC 1/2] qdev/qbus: Add hidden device support Sameeh Jubran
2018-10-25 14:06 ` [Qemu-devel] [RFC 2/2] virtio-net: Implement VIRTIO_NET_F_STANDBY feature Sameeh Jubran
2018-10-25 18:01 ` [Qemu-devel] [RFC 0/2] Attempt to implement the standby feature for assigned network devices Sameeh Jubran
2018-12-05 16:18   ` Michael Roth
2018-12-05 17:09     ` [Qemu-devel] [libvirt] " Peter Krempa
2018-12-05 17:22       ` Michael S. Tsirkin
2018-12-05 17:26         ` Daniel P. Berrangé
2018-12-05 17:43       ` Daniel P. Berrangé
2018-10-25 22:17 ` Michael S. Tsirkin [this message]
2018-12-05 17:18 ` [Qemu-devel] " Daniel P. Berrangé
2018-12-05 17:26   ` Michael S. Tsirkin
2018-12-05 20:24   ` Michael Roth
2018-12-05 20:44     ` Michael Roth
2018-12-05 20:58       ` Michael S. Tsirkin
2018-12-05 20:57     ` Michael S. Tsirkin
2018-12-06 10:01       ` Daniel P. Berrangé
2018-12-06 10:06     ` Daniel P. Berrangé
2018-12-07 16:36       ` Eduardo Habkost
2018-12-07 16:46         ` Daniel P. Berrangé
2018-12-07 18:26           ` Michael S. Tsirkin
2018-12-07 17:50       ` Roman Kagan
2018-12-07 18:20       ` 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=20181025181643-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sameeh@daynix.com \
    --cc=yan@daynix.com \
    /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).