On 1.03.2025 00:38, Fabiano Rosas wrote:
Cédric Le Goater <c...@redhat.com> writes:

On 2/27/25 23:01, Maciej S. Szmigiero wrote:
On 27.02.2025 07:59, Cédric Le Goater wrote:
On 2/19/25 21:34, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com>

Update the VFIO documentation at docs/devel/migration describing the
changes brought by the multifd device state transfer.

Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
---
   docs/devel/migration/vfio.rst | 80 +++++++++++++++++++++++++++++++----
   1 file changed, 71 insertions(+), 9 deletions(-)

diff --git a/docs/devel/migration/vfio.rst b/docs/devel/migration/vfio.rst
index c49482eab66d..d9b169d29921 100644
--- a/docs/devel/migration/vfio.rst
+++ b/docs/devel/migration/vfio.rst
@@ -16,6 +16,37 @@ helps to reduce the total downtime of the VM. VFIO devices 
opt-in to pre-copy
   support by reporting the VFIO_MIGRATION_PRE_COPY flag in the
   VFIO_DEVICE_FEATURE_MIGRATION ioctl.

Please add a new "multifd" documentation subsection at the end of the file
with this part :

+Starting from QEMU version 10.0 there's a possibility to transfer VFIO device
+_STOP_COPY state via multifd channels. This helps reduce downtime - especially
+with multiple VFIO devices or with devices having a large migration state.
+As an additional benefit, setting the VFIO device to _STOP_COPY state and
+saving its config space is also parallelized (run in a separate thread) in
+such migration mode.
+
+The multifd VFIO device state transfer is controlled by
+"x-migration-multifd-transfer" VFIO device property. This property defaults to
+AUTO, which means that VFIO device state transfer via multifd channels is
+attempted in configurations that otherwise support it.
+

Done - I also moved the parts about x-migration-max-queued-buffers
and x-migration-load-config-after-iter description there since
obviously they wouldn't make sense being left alone in the top section.

I was expecting a much more detailed explanation on the design too  :

   * in the cover letter
   * in the hw/vfio/migration-multifd.c
   * in some new file under docs/devel/migration/

I forgot to add  :

       * guide on how to use this new feature from QEMU and libvirt.
         something we can refer to for tests. That's a must have.
       * usage scenarios
         There are some benefits but it is not obvious a user would
         like to use multiple VFs in one VM, please explain.
         This is a major addition which needs justification anyhow
       * pros and cons

I'm not sure what descriptions you exactly want in these places,

Looking from the VFIO subsystem, the way this series works is very opaque.
There are a couple of a new migration handlers, new threads, new channels,
etc. It has been discussed several times with migration folks, please provide
a summary for a new reader as ignorant as everyone would be when looking at
a new file.


but since
that's just documentation (not code) it could be added after the code freeze...

That's the risk of not getting any ! and the initial proposal should be
discussed before code freeze.

For the general framework, I was expecting an extension of a "multifd"
subsection under :

    https://qemu.readthedocs.io/en/v9.2.0/devel/migration/features.html

but it doesn't exist :/

Hi, see if this helps. Let me know what can be improved and if something
needs to be more detailed. Please ignore the formatting, I'll send a
proper patch after the carnaval.

@Maciej, it's probably better if you keep your docs separate anyway so
we don't add another dependency. I can merge them later.

That's a very good idea, thanks for writing this multifd doc Fabiano!

multifd.rst:

Multifd
=======

Multifd is the name given for the migration capability that enables
data transfer using multiple threads. Multifd supports all the
transport types currently in use with migration (inet, unix, vsock,
fd, file).
(..)

Thanks,
Maciej


Reply via email to