On 3/5/25 16:11, Maciej S. Szmigiero wrote:
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?
yes. It has been discussed and we can still merge stuff until the
hard freeze. After that, it's fixes only.
Thanks,
C.
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
