On 02/03/2025 16:59, Maciej S. Szmigiero wrote:
External email: Use caution opening links or attachments
On 2.03.2025 15:54, Maciej S. Szmigiero wrote:
On 2.03.2025 15:53, Avihai Horon wrote:
On 19/02/2025 22:34, 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.
I still think it's better to limit the number of bytes rather than
number of buffers:
1. To the average user the number of buffers doesn't really mean
anything. They have to open the code and see what is the size of a
single buffer and then choose their value.
2. Currently VFIO migration buffer size is 1MB. If later it's
changed to 2MB for example, users will have to adjust their
configuration accordingly. With number of bytes, the configuration
remains the same no matter what is the VFIO migration buffer size.
Sorry Avihai, but we're a little more than week from code freeze
so it's really not a time for more than cosmetic changes.
And if you really, really want to have queued buffers size limit
that's something could be added later as additional
x-migration-max-queued-buffers-size or something property
since these limits aren't exclusive.
Sure, I agree.
It's not urgent nor mandatory for now, I just wanted to express my
opinion :)
Thanks.
Thanks,
Maciej
