qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Jens Freimann <jfreimann@redhat.com>
Cc: ehabkost@redhat.com, mst@redhat.com, aadam@redhat.com,
	qemu-devel@nongnu.org, dgilbert@redhat.com, laine@redhat.com,
	ailan@redhat.com, parav@mellanox.com
Subject: Re: [PATCH v3 10/10] vfio: unplug failover primary device before migration
Date: Tue, 15 Oct 2019 19:52:12 -0600	[thread overview]
Message-ID: <20191015195212.27e0f944@x1.home> (raw)
In-Reply-To: <20191011112015.11785-11-jfreimann@redhat.com>

On Fri, 11 Oct 2019 13:20:15 +0200
Jens Freimann <jfreimann@redhat.com> wrote:

> As usual block all vfio-pci devices from being migrated, but make an
> exception for failover primary devices. This is achieved by setting
> unmigratable to 0 but also add a migration blocker for all vfio-pci
> devices except failover primary devices. These will be unplugged before
> migration happens by the migration handler of the corresponding
> virtio-net standby device.
> 
> Signed-off-by: Jens Freimann <jfreimann@redhat.com>
> ---
>  hw/vfio/pci.c | 35 ++++++++++++++++++++++++++++++++++-
>  hw/vfio/pci.h |  2 ++
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index c5e6fe61cb..64cf8e07d9 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -40,6 +40,9 @@
>  #include "pci.h"
>  #include "trace.h"
>  #include "qapi/error.h"
> +#include "migration/blocker.h"
> +#include "qemu/option.h"
> +#include "qemu/option_int.h"
>  
>  #define TYPE_VFIO_PCI "vfio-pci"
>  #define PCI_VFIO(obj)    OBJECT_CHECK(VFIOPCIDevice, obj, TYPE_VFIO_PCI)
> @@ -2698,6 +2701,12 @@ static void vfio_unregister_req_notifier(VFIOPCIDevice *vdev)
>      vdev->req_enabled = false;
>  }
>  
> +static int has_net_failover_arg(void *opaque, const char *name,
> +                           const char *value, Error **errp)
> +{
> +    return (strcmp(name, "net_failover_pair_id") == 0);
> +}
> +
>  static void vfio_realize(PCIDevice *pdev, Error **errp)
>  {
>      VFIOPCIDevice *vdev = PCI_VFIO(pdev);
> @@ -2710,6 +2719,20 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>      int groupid;
>      int i, ret;
>      bool is_mdev;
> +    uint16_t class_id;
> +
> +    if (qemu_opt_foreach(pdev->qdev.opts, has_net_failover_arg,
> +                         (void *) pdev->qdev.opts, &err) == 0) {

Why do we need a qemu_opt_foreach here versus testing
vdev->net_failover_pair_id as you do below or similar to how we test
sysfsdev immediately below this chunk?

> +        error_setg(&vdev->migration_blocker,
> +                "VFIO device doesn't support migration");
> +        ret = migrate_add_blocker(vdev->migration_blocker, &err);

Where's the migrate_del_blocker()/error_free() for any other realize
error or device removal?

> +        if (err) {
> +            error_propagate(errp, err);
> +            error_free(vdev->migration_blocker);
> +        }

As Connie noted, unclear if this aborts or continues without a
migration blocker, which would be bad.

> +    } else {
> +        pdev->qdev.allow_unplug_during_migration = true;
> +    }
>  
>      if (!vdev->vbasedev.sysfsdev) {
>          if (!(~vdev->host.domain || ~vdev->host.bus ||
> @@ -2812,6 +2835,14 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>          goto error;
>      }
>  
> +    if (vdev->net_failover_pair_id != NULL) {
> +        class_id = pci_get_word(pdev->config + PCI_CLASS_DEVICE);
> +        if (class_id != PCI_CLASS_NETWORK_ETHERNET) {
> +            error_setg(errp, "failover device is not an Ethernet device");
> +            goto error;
> +        }
> +    }

Not clear to me why we do this separate from setting up the migration
blocker or why we use a different mechanism to test for the property.

> +
>      /* vfio emulates a lot for us, but some bits need extra love */
>      vdev->emulated_config_bits = g_malloc0(vdev->config_size);
>  
> @@ -3110,6 +3141,8 @@ static Property vfio_pci_dev_properties[] = {
>                              display, ON_OFF_AUTO_OFF),
>      DEFINE_PROP_UINT32("xres", VFIOPCIDevice, display_xres, 0),
>      DEFINE_PROP_UINT32("yres", VFIOPCIDevice, display_yres, 0),
> +    DEFINE_PROP_STRING("net_failover_pair_id", VFIOPCIDevice,
> +            net_failover_pair_id),

Should this and the Ethernet class test be done in PCIDevice?  The
migration aspect is the only thing unique to vfio since we don't
otherwise support it, right?  For instance, I should be able to
setup an emulated NIC with this failover pair id too, right?  Thanks,

Alex

>      DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice,
>                         intx.mmap_timeout, 1100),
>      DEFINE_PROP_BIT("x-vga", VFIOPCIDevice, features,
> @@ -3152,7 +3185,7 @@ static Property vfio_pci_dev_properties[] = {
>  
>  static const VMStateDescription vfio_pci_vmstate = {
>      .name = "vfio-pci",
> -    .unmigratable = 1,
> +    .unmigratable = 0,
>  };
>  
>  static void vfio_pci_dev_class_init(ObjectClass *klass, void *data)
> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> index 834a90d646..da4417071a 100644
> --- a/hw/vfio/pci.h
> +++ b/hw/vfio/pci.h
> @@ -134,6 +134,7 @@ typedef struct VFIOPCIDevice {
>      PCIHostDeviceAddress host;
>      EventNotifier err_notifier;
>      EventNotifier req_notifier;
> +    char *net_failover_pair_id;
>      int (*resetfn)(struct VFIOPCIDevice *);
>      uint32_t vendor_id;
>      uint32_t device_id;
> @@ -168,6 +169,7 @@ typedef struct VFIOPCIDevice {
>      bool no_vfio_ioeventfd;
>      bool enable_ramfb;
>      VFIODisplay *dpy;
> +    Error *migration_blocker;
>  } VFIOPCIDevice;
>  
>  uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);



  parent reply	other threads:[~2019-10-16  1:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 11:20 [PATCH v3 0/10] add failover feature for assigned network devices Jens Freimann
2019-10-11 11:20 ` [PATCH v3 01/10] qdev/qbus: add hidden device support Jens Freimann
2019-10-14  9:46   ` Cornelia Huck
2019-10-14 12:02     ` Jens Freimann
2019-10-15 19:19   ` Alex Williamson
2019-10-16  7:04     ` Jens Freimann
2019-10-11 11:20 ` [PATCH v3 02/10] pci: mark devices partially unplugged Jens Freimann
2019-10-16  1:53   ` Alex Williamson
2019-10-11 11:20 ` [PATCH v3 03/10] pci: mark device having guest unplug request pending Jens Freimann
2019-10-11 11:20 ` [PATCH v3 04/10] qapi: add unplug primary event Jens Freimann
2019-10-11 11:20 ` [PATCH v3 05/10] qapi: add failover negotiated event Jens Freimann
2019-10-11 11:20 ` [PATCH v3 06/10] migration: allow unplug during migration for failover devices Jens Freimann
2019-10-11 11:20 ` [PATCH v3 07/10] migration: add new migration state wait-unplug Jens Freimann
2019-10-11 12:57   ` Michael S. Tsirkin
2019-10-11 14:22     ` Jens Freimann
2019-10-11 16:49   ` Dr. David Alan Gilbert
2019-10-11 17:11   ` Dr. David Alan Gilbert
2019-10-15  9:45     ` Jens Freimann
2019-10-15 10:50       ` Dr. David Alan Gilbert
2019-10-16  7:07         ` Jens Freimann
2019-10-11 11:20 ` [PATCH v3 08/10] libqos: tolerate wait-unplug migration state Jens Freimann
2019-10-11 11:20 ` [PATCH v3 09/10] net/virtio: add failover support Jens Freimann
2019-10-11 11:20 ` [PATCH v3 10/10] vfio: unplug failover primary device before migration Jens Freimann
2019-10-14 10:05   ` Cornelia Huck
2019-10-16  1:52   ` Alex Williamson [this message]
2019-10-16 20:18     ` Jens Freimann
2019-10-17  0:39       ` Alex Williamson
2019-10-17  7:45         ` Jens Freimann
2019-10-11 14:28 ` [PATCH v3 0/10] add failover feature for assigned network devices Michael S. Tsirkin
2019-10-11 16:04 ` no-reply
2019-10-15 19:03 ` Alex Williamson
2019-10-15 21:17   ` Michael S. Tsirkin
2019-10-17 10:33   ` Jens Freimann
2019-10-17 12:51     ` Alex Williamson
2019-10-17 14:04       ` Jens Freimann

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=20191015195212.27e0f944@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=aadam@redhat.com \
    --cc=ailan@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jfreimann@redhat.com \
    --cc=laine@redhat.com \
    --cc=mst@redhat.com \
    --cc=parav@mellanox.com \
    --cc=qemu-devel@nongnu.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).