qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] cf2549: vfio: Make migration support experime


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] cf2549: vfio: Make migration support experimental
Date: Mon, 23 Nov 2020 14:53:37 -0800

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: cf254988a50d4164c86a356c80b8d3ae0ccaa005
      
https://github.com/qemu/qemu/commit/cf254988a50d4164c86a356c80b8d3ae0ccaa005
  Author: Alex Williamson <alex.williamson@redhat.com>
  Date:   2020-11-23 (Mon, 23 Nov 2020)

  Changed paths:
    M hw/vfio/migration.c
    M hw/vfio/pci.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio: Make migration support experimental

Support for migration of vfio devices is still in flux.  Developers
are attempting to add support for new devices and new architectures,
but none are yet readily available for validation.  We have concerns
whether we're transferring device resources at the right point in the
migration, whether we're guaranteeing that updates during pre-copy are
migrated, and whether we can provide bit-stream compatibility should
any of this change.  Even the question of whether devices should
participate in dirty page tracking during pre-copy seems contentious.
In short, migration support has not had enough soak time and it feels
premature to mark it as supported.

Create an experimental option such that we can continue to develop.

[Retaining previous acks/reviews for a previously identical code
 change with different specifics in the commit log.]

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


  Commit: bb0990d1740f6dced5b50a923677034c9399c213
      
https://github.com/qemu/qemu/commit/bb0990d1740f6dced5b50a923677034c9399c213
  Author: Kirti Wankhede <kwankhede@nvidia.com>
  Date:   2020-11-23 (Mon, 23 Nov 2020)

  Changed paths:
    M hw/vfio/common.c
    M hw/vfio/pci.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  vfio: Change default dirty pages tracking behavior during migration

By default dirty pages tracking is enabled during iterative phase
(pre-copy phase).
Added per device opt-out option 'x-pre-copy-dirty-page-tracking' to
disable dirty pages tracking during iterative phase. If the option
'x-pre-copy-dirty-page-tracking=off' is set for any VFIO device, dirty
pages tracking during iterative phase will be disabled.

Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>


  Commit: 23895cbd82be95428e90168b12e925d0d3ca2f06
      
https://github.com/qemu/qemu/commit/23895cbd82be95428e90168b12e925d0d3ca2f06
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-11-23 (Mon, 23 Nov 2020)

  Changed paths:
    M hw/vfio/common.c
    M hw/vfio/migration.c
    M hw/vfio/pci.c
    M include/hw/vfio/vfio-common.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20201123.0' 
into staging

VFIO update 2020-11-23

 * Enable pre-copy dirty page tracking by default (Kirti Wankhede)

 * Mark migration as experimental (Alex Williamson)

# gpg: Signature made Mon 23 Nov 2020 17:10:58 GMT
# gpg:                using RSA key 239B9B6E3BB08B22
# gpg: Good signature from "Alex Williamson <alex.williamson@redhat.com>" [full]
# gpg:                 aka "Alex Williamson <alex@shazbot.org>" [full]
# gpg:                 aka "Alex Williamson <alwillia@redhat.com>" [full]
# gpg:                 aka "Alex Williamson <alex.l.williamson@gmail.com>" 
[full]
# Primary key fingerprint: 42F6 C04E 540B D1A9 9E7B  8A90 239B 9B6E 3BB0 8B22

* remotes/awilliam/tags/vfio-update-20201123.0:
  vfio: Change default dirty pages tracking behavior during migration
  vfio: Make migration support experimental

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/fb764373eaf7...23895cbd82be



reply via email to

[Prev in Thread] Current Thread [Next in Thread]