On 5.03.2025 10:19, Cédric Le Goater wrote:
On 3/4/25 23:04, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com>
Allow capping the maximum count 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 the limit by default by setting it to UINT64_MAX.
I agree with Avihai that a limit on bytes would make more sense.
-rc0 is in ~2w. We have time to prepare a patch for this.
According to https://wiki.qemu.org/Planning/10.0 "Soft feature freeze"
is next Tuesday.
Do you still want to have that patch with a new byte limit applied
after that?
Should there be a correlation with :
/*
* This is an arbitrary size based on migration of mlx5 devices, where
typically
* total device migration size is on the order of 100s of MB. Testing with
* larger values, e.g. 128MB and 1GB, did not show a performance
improvement.
*/
#define VFIO_MIG_DEFAULT_DATA_BUFFER_SIZE (1 * MiB)
I think we could simply have a counter of queued bytes up to this point
and then abort/error out if the set amount of bytes is exceeded.
Thanks,
C.
Thanks,
Maciej
