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: Wed, 16 Oct 2019 18:39:58 -0600 [thread overview]
Message-ID: <20191016183958.2f66f055@x1.home> (raw)
In-Reply-To: <20191016201847.izgvkxfoepci4w23@jenstp.localdomain>
On Wed, 16 Oct 2019 22:18:47 +0200
Jens Freimann <jfreimann@redhat.com> wrote:
> On Tue, Oct 15, 2019 at 07:52:12PM -0600, Alex Williamson wrote:
> >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?
>
> We don't need it, I will change it and move it to where we check for
> the PCI class.
> >
> >> + 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.
>
> It aborts in my test. PCI realize propagates it further and eventually
> it leads to aborting qemu.
>
> It looks like this now:
>
> if (!pdev->net_failover_pair_id) {
> error_setg(&vdev->migration_blocker,
> "VFIO device doesn't support migration");
> ret = migrate_add_blocker(vdev->migration_blocker, &err);
> if (err) {
> error_propagate(errp, err);
> } else {
> error_propagate(errp, vdev->migration_blocker);
> }
> goto error;
This unconditionally goes to error when we don't have a failover pair
set :-\
I suspect we don't want any sort of error propagate in the success
case, the migration_blocker pre-defines the error when the migration is
blocked, right? Thanks,
Alex
> } else {
> pdev->qdev.allow_unplug_during_migration = true;
> }
>
> >> + } 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.
>
> I'm moving this check to hw/pci/pci.c as you suggested.
>
> >> +
> >> /* 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,
>
> Yes, we can do it in PCIDevice. Using it with an emulated device.
> It wouldn't make sense for production but could make sense for
> testing purposes.
>
> Thanks for the review!
>
> regards,
> Jens
next prev parent reply other threads:[~2019-10-17 0:41 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
2019-10-16 20:18 ` Jens Freimann
2019-10-17 0:39 ` Alex Williamson [this message]
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=20191016183958.2f66f055@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).