diff options
| author | Maciej S. Szmigiero <maciej.szmigiero@oracle.com> | 2025-07-15 16:37:37 +0200 |
|---|---|---|
| committer | Cédric Le Goater <clg@redhat.com> | 2025-07-15 17:11:12 +0200 |
| commit | 300dcf58b72fa1635190b19f102231b0775e93cb (patch) | |
| tree | ef712b0fe23af924c43bbab81ec40948d9027aa2 /docs | |
| parent | 6380b0a02fbdac253b8a98b300398319ab655237 (diff) | |
| download | qemu-300dcf58b72fa1635190b19f102231b0775e93cb.zip qemu-300dcf58b72fa1635190b19f102231b0775e93cb.tar.gz qemu-300dcf58b72fa1635190b19f102231b0775e93cb.tar.bz2 | |
vfio/migration: Max in-flight VFIO device state buffers size limit
Allow capping the maximum total size of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source could
theoretically cause the target QEMU to allocate unlimited amounts of memory
for buffers-in-flight.
Since this is not expected to be a realistic threat in most of VFIO live
migration use cases and the right value depends on the particular setup
disable this limit by default by setting it to UINT64_MAX.
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Avihai Horon <avihaih@nvidia.com>
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Link: https://lore.kernel.org/qemu-devel/4f7cad490988288f58e36b162d7a888ed7e7fd17.1752589295.git.maciej.szmigiero@oracle.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/devel/migration/vfio.rst | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/docs/devel/migration/vfio.rst b/docs/devel/migration/vfio.rst index dae3a98..0790e50 100644 --- a/docs/devel/migration/vfio.rst +++ b/docs/devel/migration/vfio.rst @@ -248,6 +248,19 @@ The multifd VFIO device state transfer is controlled by AUTO, which means that VFIO device state transfer via multifd channels is attempted in configurations that otherwise support it. +Since the target QEMU needs to load device state buffers in-order it needs to +queue incoming buffers until they can be loaded into the device. +This means that a malicious QEMU source could theoretically cause the target +QEMU to allocate unlimited amounts of memory for such buffers-in-flight. + +The "x-migration-max-queued-buffers-size" property allows capping the total size +of these VFIO device state buffers queued at the destination. + +Because a malicious QEMU source causing OOM on the target is not expected to be +a realistic threat in most of VFIO live migration use cases and the right value +depends on the particular setup by default this queued buffers size limit is +disabled by setting it to UINT64_MAX. + Some host platforms (like ARM64) require that VFIO device config is loaded only after all iterables were loaded, during non-iterables loading phase. Such interlocking is controlled by "x-migration-load-config-after-iter" VFIO |