On 7.07.2025 11:29, Avihai Horon wrote:
On 24/06/2025 20:51, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
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.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigi...@oracle.com>
Reviewed-by: Avihai Horon <avih...@nvidia.com>
Thanks.
But do we really need both x-migration-max-queued-buffers and
x-migration-max-queued-buffers-size?
I think one is sufficient.
I vote for x-migration-max-queued-buffers-size as the actual memory limit won't
change depending on VFIO migration buffer size.
If just one of these limits were to be implemented my vote would be also for
the size limit rather than the count limit.
However, if you pick x-migration-max-queued-buffers, maybe it's worth
mentioning in the docs what is the size of a buffer?
I think it's not a constant number since it's a
MIN(VFIO_MIG_DEFAULT_DATA_BUFFER_SIZE, stop_copy_size)?
On the other hand, one could say it's "at most
VFIO_MIG_DEFAULT_DATA_BUFFER_SIZE".
Thanks.
Thanks,
Maciej
