mbox series

[0/9] vfio/migration: Implement VFIO migration protocol v2

Message ID 20220512154320.19697-1-avihaih@nvidia.com (mailing list archive)
Headers show
Series vfio/migration: Implement VFIO migration protocol v2 | expand

Message

Avihai Horon May 12, 2022, 3:43 p.m. UTC 
Hello,

Following VFIO migration protocol v2 acceptance in kernel, this series
implements VFIO migration according to the new v2 protocol and replaces
the now deprecated v1 implementation.

The main differences between v1 and v2 migration protocols are:
1. VFIO device state is represented as a finite state machine instead of
   a bitmap.

2. The migration interface with kernel is done using VFIO_DEVICE_FEATURE
   ioctl and normal read() and write() instead of the migration region
   used in v1.

3. Migration protocol v2 currently doesn't support the pre-copy phase of
   migration.

Full description of the v2 protocol and the differences from v1 can be
found here [1].

Patches 1-5 are prep patches importing the new uAPI headers, fixing bugs
and adding QEMUFile function that will be used later.

Patches 6-9 are the main patches that replace the v1 implementation with
v2.

Thanks.

[1]
https://lore.kernel.org/all/20220224142024.147653-10-yishaih@nvidia.com/

Avihai Horon (9):
  linux-headers: Update headers to v5.18-rc6
  vfio: Fix compilation errors caused by VFIO migration v1 deprecation
  vfio/migration: Fix NULL pointer dereference bug
  vfio/migration: Skip pre-copy if dirty page tracking is not supported
  migration/qemu-file: Add qemu_file_get_to_fd()
  vfio/migration: Implement VFIO migration protocol v2
  vfio/migration: Reset device if setting recover state fails
  vfio: Alphabetize migration section of VFIO trace-events file
  docs/devel: Align vfio-migration docs to VFIO migration v2

 docs/devel/vfio-migration.rst                 |  77 +--
 hw/vfio/common.c                              |  21 +-
 hw/vfio/migration.c                           | 640 ++++--------------
 hw/vfio/trace-events                          |  25 +-
 include/hw/vfio/vfio-common.h                 |   8 +-
 .../linux/input-event-codes.h                 |  25 +-
 .../standard-headers/linux/virtio_config.h    |   6 +
 .../standard-headers/linux/virtio_crypto.h    |  82 ++-
 linux-headers/asm-arm64/kvm.h                 |  16 +
 linux-headers/asm-generic/mman-common.h       |   2 +
 linux-headers/asm-mips/mman.h                 |   2 +
 linux-headers/linux/kvm.h                     |  27 +-
 linux-headers/linux/psci.h                    |   4 +
 linux-headers/linux/userfaultfd.h             |   8 +-
 linux-headers/linux/vfio.h                    | 406 ++++++-----
 linux-headers/linux/vhost.h                   |   7 +
 migration/migration.c                         |   5 +
 migration/migration.h                         |   3 +
 migration/qemu-file.c                         |  34 +
 migration/qemu-file.h                         |   1 +
 20 files changed, 618 insertions(+), 781 deletions(-)

Comments

Alex Williamson May 12, 2022, 6:02 p.m. UTC | #1 
On Thu, 12 May 2022 18:43:11 +0300
Avihai Horon <avihaih@nvidia.com> wrote:

> Hello,
> 
> Following VFIO migration protocol v2 acceptance in kernel, this series
> implements VFIO migration according to the new v2 protocol and replaces
> the now deprecated v1 implementation.

Let's not bottleneck others waiting on a linux header file update on
also incorporating v2 support.  In the short term we just need the
first two patches here.

Are there any objections to folding those patches together for the sake
of bisection?  Thanks,

Alex
Cornelia Huck May 13, 2022, 7:04 a.m. UTC | #2 
On Thu, May 12 2022, Alex Williamson <alex.williamson@redhat.com> wrote:

> On Thu, 12 May 2022 18:43:11 +0300
> Avihai Horon <avihaih@nvidia.com> wrote:
>
>> Hello,
>> 
>> Following VFIO migration protocol v2 acceptance in kernel, this series
>> implements VFIO migration according to the new v2 protocol and replaces
>> the now deprecated v1 implementation.
>
> Let's not bottleneck others waiting on a linux header file update on
> also incorporating v2 support.  In the short term we just need the
> first two patches here.
>
> Are there any objections to folding those patches together for the sake
> of bisection?  Thanks,
>
> Alex

I think folding the headers update and the fixup together makes a lot of
sense. And yes, I'd like to see it in QEMU quickly in order to unblock
other series.