qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Avihai Horon <avihaih@nvidia.com>
Cc: qemu-devel@nongnu.org, "Cédric Le Goater" <clg@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Leonardo Bras" <leobras@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Paolo Bonzini" <pbonzini@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>,
	"Joao Martins" <joao.m.martins@oracle.com>
Subject: Re: [PATCH v5 8/9] vfio/migration: Add x-allow-pre-copy VFIO device property
Date: Thu, 1 Jun 2023 14:22:31 -0600	[thread overview]
Message-ID: <20230601142231.78b15326.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230530144821.1557-9-avihaih@nvidia.com>

On Tue, 30 May 2023 17:48:20 +0300
Avihai Horon <avihaih@nvidia.com> wrote:

> Add a new VFIO device property x-allow-pre-copy to keep migration
> compatibility to/from older QEMU versions that don't have VFIO pre-copy
> support.

This doesn't make sense to me, vfio migration is not currently
supported, it can only be enabled via an experimental flag.  AFAIK we
have no obligation to maintain migration compatibility against
experimental features.  Is there any other reason we need a flag to
disable pre-copy?

OTOH, should this series finally remove the experimental migration
flag?  Do we require Joao's vIOMMU support to finally make it
supportable?  Is there something else?  Thanks,

Alex

> Signed-off-by: Avihai Horon <avihaih@nvidia.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
> ---
>  include/hw/vfio/vfio-common.h | 1 +
>  hw/core/machine.c             | 1 +
>  hw/vfio/migration.c           | 3 ++-
>  hw/vfio/pci.c                 | 2 ++
>  4 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
> index 1db901c194..a53ecbe2e0 100644
> --- a/include/hw/vfio/vfio-common.h
> +++ b/include/hw/vfio/vfio-common.h
> @@ -146,6 +146,7 @@ typedef struct VFIODevice {
>      VFIOMigration *migration;
>      Error *migration_blocker;
>      OnOffAuto pre_copy_dirty_page_tracking;
> +    bool allow_pre_copy;
>      bool dirty_pages_supported;
>      bool dirty_tracking;
>  } VFIODevice;
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 1000406211..64ac3fe38e 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -41,6 +41,7 @@
>  
>  GlobalProperty hw_compat_8_0[] = {
>      { "migration", "multifd-flush-after-each-section", "on"},
> +    { "vfio-pci", "x-allow-pre-copy", "false" },
>  };
>  const size_t hw_compat_8_0_len = G_N_ELEMENTS(hw_compat_8_0);
>  
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index d8f6a22ae1..cb6923ed3f 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -323,7 +323,8 @@ static bool vfio_precopy_supported(VFIODevice *vbasedev)
>  {
>      VFIOMigration *migration = vbasedev->migration;
>  
> -    return migration->mig_flags & VFIO_MIGRATION_PRE_COPY;
> +    return vbasedev->allow_pre_copy &&
> +           migration->mig_flags & VFIO_MIGRATION_PRE_COPY;
>  }
>  
>  /* ---------------------------------------------------------------------- */
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 73874a94de..c69813af7f 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -3335,6 +3335,8 @@ static Property vfio_pci_dev_properties[] = {
>      DEFINE_PROP_ON_OFF_AUTO("x-pre-copy-dirty-page-tracking", VFIOPCIDevice,
>                              vbasedev.pre_copy_dirty_page_tracking,
>                              ON_OFF_AUTO_ON),
> +    DEFINE_PROP_BOOL("x-allow-pre-copy", VFIOPCIDevice,
> +                     vbasedev.allow_pre_copy, true),
>      DEFINE_PROP_ON_OFF_AUTO("display", VFIOPCIDevice,
>                              display, ON_OFF_AUTO_OFF),
>      DEFINE_PROP_UINT32("xres", VFIOPCIDevice, display_xres, 0),



  reply	other threads:[~2023-06-01 20:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 14:48 [PATCH v5 0/9] migration: Add switchover ack capability and VFIO precopy support Avihai Horon
2023-05-30 14:48 ` [PATCH v5 1/9] migration: Add switchover ack capability Avihai Horon
2023-06-15 12:38   ` YangHang Liu
2023-06-15 13:49     ` Cédric Le Goater
2023-06-19  9:37       ` Avihai Horon
2023-05-30 14:48 ` [PATCH v5 2/9] migration: Implement switchover ack logic Avihai Horon
2023-06-05 22:06   ` Alex Williamson
2023-06-06 12:12     ` Avihai Horon
2023-06-08 18:32       ` Alex Williamson
2023-06-11  7:45         ` Avihai Horon
2023-05-30 14:48 ` [PATCH v5 3/9] migration: Enable switchover ack capability Avihai Horon
2023-05-30 14:48 ` [PATCH v5 4/9] tests: Add migration switchover ack capability test Avihai Horon
2023-05-30 14:48 ` [PATCH v5 5/9] vfio/migration: Refactor vfio_save_block() to return saved data size Avihai Horon
2023-05-30 14:48 ` [PATCH v5 6/9] vfio/migration: Store VFIO migration flags in VFIOMigration Avihai Horon
2023-05-30 14:48 ` [PATCH v5 7/9] vfio/migration: Add VFIO migration pre-copy support Avihai Horon
2023-05-30 14:48 ` [PATCH v5 8/9] vfio/migration: Add x-allow-pre-copy VFIO device property Avihai Horon
2023-06-01 20:22   ` Alex Williamson [this message]
2023-06-04  9:33     ` Avihai Horon
2023-06-05 14:56       ` Alex Williamson
2023-06-06 11:59         ` Avihai Horon
2023-06-06 13:40           ` Cédric Le Goater
2023-06-07  7:41             ` Avihai Horon
2023-05-30 14:48 ` [PATCH v5 9/9] vfio/migration: Add support for switchover ack capability Avihai Horon
2023-05-30 15:15   ` Cédric Le Goater
2023-06-16  9:35 ` [PATCH v5 0/9] migration: Add switchover ack capability and VFIO precopy support YangHang Liu

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=20230601142231.78b15326.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=clg@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=jgg@nvidia.com \
    --cc=joao.m.martins@oracle.com \
    --cc=kwankhede@nvidia.com \
    --cc=leobras@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=maorg@nvidia.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=targupta@nvidia.com \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.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).