qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: qemu-devel@nongnu.org, Cedric Le Goater <clg@redhat.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Tarun Gupta <targupta@nvidia.com>,
	Avihai Horon <avihaih@nvidia.com>
Subject: Re: [PATCH v5 13/15] vfio/migration: Block migration with vIOMMU
Date: Tue, 7 Mar 2023 09:38:51 -0700	[thread overview]
Message-ID: <20230307093851.2d820df0.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230307125450.62409-14-joao.m.martins@oracle.com>

On Tue,  7 Mar 2023 12:54:48 +0000
Joao Martins <joao.m.martins@oracle.com> wrote:

> Migrating with vIOMMU will require either tracking maximum
> IOMMU supported address space (e.g. 39/48 address width on Intel)
> or range-track current mappings and dirty track the new ones
> post starting dirty tracking. This will be done as a separate
> series, so add a live migration blocker until that is fixed.
> 
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
> ---
>  hw/vfio/common.c              | 46 +++++++++++++++++++++++++++++++++++
>  hw/vfio/migration.c           |  5 ++++
>  hw/vfio/pci.c                 |  1 +
>  include/hw/vfio/vfio-common.h |  2 ++
>  4 files changed, 54 insertions(+)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 2639b393a781..2b9bcf70aa36 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -362,6 +362,7 @@ bool vfio_mig_active(void)
>  }
>  
>  static Error *multiple_devices_migration_blocker;
> +static Error *giommu_migration_blocker;
>  
>  static unsigned int vfio_migratable_device_num(void)
>  {
> @@ -413,6 +414,51 @@ void vfio_unblock_multiple_devices_migration(void)
>      multiple_devices_migration_blocker = NULL;
>  }
>  
> +static bool vfio_viommu_preset(void)
> +{
> +    VFIOAddressSpace *space;
> +
> +    QLIST_FOREACH(space, &vfio_address_spaces, list) {
> +        if (space->as != &address_space_memory) {
> +            return true;
> +        }
> +    }
> +
> +    return false;
> +}
> +
> +int vfio_block_giommu_migration(Error **errp)
> +{
> +    int ret;
> +
> +    if (giommu_migration_blocker ||
> +        !vfio_viommu_preset()) {
> +        return 0;
> +    }
> +
> +    error_setg(&giommu_migration_blocker,
> +               "Migration is currently not supported with vIOMMU enabled");
> +    ret = migrate_add_blocker(giommu_migration_blocker, errp);
> +    if (ret < 0) {
> +        error_free(giommu_migration_blocker);
> +        giommu_migration_blocker = NULL;
> +    }
> +
> +    return ret;
> +}
> +
> +void vfio_unblock_giommu_migration(void)
> +{
> +    if (!giommu_migration_blocker ||
> +        vfio_viommu_preset()) {
> +        return;
> +    }
> +
> +    migrate_del_blocker(giommu_migration_blocker);
> +    error_free(giommu_migration_blocker);
> +    giommu_migration_blocker = NULL;
> +}
> +
>  static void vfio_set_migration_error(int err)
>  {
>      MigrationState *ms = migrate_get_current();
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index a2c3d9bade7f..776fd2d7cdf3 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -634,6 +634,11 @@ int vfio_migration_probe(VFIODevice *vbasedev, Error **errp)
>          return ret;
>      }
>  
> +    ret = vfio_block_giommu_migration(errp);
> +    if (ret) {
> +        return ret;
> +    }
> +
>      trace_vfio_migration_probe(vbasedev->name);
>      return 0;
>  
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 939dcc3d4a9e..30a271eab38c 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -3185,6 +3185,7 @@ static void vfio_instance_finalize(Object *obj)
>       */
>      vfio_put_device(vdev);
>      vfio_put_group(group);
> +    vfio_unblock_giommu_migration();
>  }

Hmm, doesn't this mean we're adding the viommu migration blocker in
common code but only removing it in pci code?  Granted that only PCI
devices currently have IOMMUs, but ick.  Thanks,

Alex



  reply	other threads:[~2023-03-07 16:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 12:54 [PATCH v5 00/15] vfio/migration: Device dirty page tracking Joao Martins
2023-03-07 12:54 ` [PATCH v5 01/15] vfio/common: Fix error reporting in vfio_get_dirty_bitmap() Joao Martins
2023-03-07 12:54 ` [PATCH v5 02/15] vfio/common: Fix wrong %m usages Joao Martins
2023-03-07 12:54 ` [PATCH v5 03/15] vfio/common: Abort migration if dirty log start/stop/sync fails Joao Martins
2023-03-07 12:54 ` [PATCH v5 04/15] vfio/common: Add VFIOBitmap and alloc function Joao Martins
2023-03-07 12:54 ` [PATCH v5 05/15] vfio/common: Add helper to validate iova/end against hostwin Joao Martins
2023-03-07 12:54 ` [PATCH v5 06/15] vfio/common: Use a single tracepoint for skipped sections Joao Martins
2023-03-07 13:27   ` Cédric Le Goater
2023-03-07 12:54 ` [PATCH v5 07/15] vfio/common: Consolidate skip/invalid section into helper Joao Martins
2023-03-07 12:54 ` [PATCH v5 08/15] vfio/common: Add helper to consolidate iova/end calculation Joao Martins
2023-03-07 13:28   ` Cédric Le Goater
2023-03-07 12:54 ` [PATCH v5 09/15] vfio/common: Record DMA mapped IOVA ranges Joao Martins
2023-03-07 13:36   ` Cédric Le Goater
2023-03-07 12:54 ` [PATCH v5 10/15] vfio/common: Add device dirty page tracking start/stop Joao Martins
2023-03-07 14:49   ` Cédric Le Goater
2023-03-07 14:54     ` Joao Martins
2023-03-07 12:54 ` [PATCH v5 11/15] vfio/common: Extract code from vfio_get_dirty_bitmap() to new function Joao Martins
2023-03-07 12:54 ` [PATCH v5 12/15] vfio/common: Add device dirty page bitmap sync Joao Martins
2023-03-07 15:16   ` Cédric Le Goater
2023-03-07 12:54 ` [PATCH v5 13/15] vfio/migration: Block migration with vIOMMU Joao Martins
2023-03-07 16:38   ` Alex Williamson [this message]
2023-03-07 16:42     ` Alex Williamson
2023-03-07 12:54 ` [PATCH v5 14/15] vfio/migration: Query device dirty page tracking support Joao Martins
2023-03-07 12:54 ` [PATCH v5 15/15] docs/devel: Document VFIO device dirty page tracking Joao Martins

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=20230307093851.2d820df0.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=clg@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kwankhede@nvidia.com \
    --cc=maorg@nvidia.com \
    --cc=qemu-devel@nongnu.org \
    --cc=targupta@nvidia.com \
    --cc=yishaih@nvidia.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).