On 5.03.2025 17:39, Cédric Le Goater wrote:
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"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the des
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"
Allow capping the maximum count of in-flight VFIO device state buffers
queued at the destination, otherwise a malicious QEMU source c
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"
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 a
On 3/4/25 23:04, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero"
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 buffe
From: "Maciej S. Szmigiero"
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 b
