On 2.04.2025 11:51, Cédric Le Goater wrote:
Hello Maciej,
On 4/1/25 14:26, Maciej S. Szmigiero wrote:
On 11.03.2025 14:04, Cédric Le Goater wrote:
On 3/7/25 14:45, Maciej S. Szmigiero wrote:
On 7.03.2025 13:03, Cédric Le Goater wrote:
On 3/7/25 11:57, Maciej S. Szmigiero wrote:
From: "Maciej S. Szmigiero" <maciej.szmigi...@oracle.com>
There's already a max in-flight VFIO device state buffers *count* limit,
no. there isn't. Do we need both ?
This is on a top of the remaining patches (x-migration-load-config-after-iter
and x-migration-max-queued-buffers) - I thought we were supposed to work
on these after the main series was merged as they are relatively non-critical.
yes. we don't need both count and size limits though, a size limit is enough.
I would also give x-migration-load-config-after-iter priority over
x-migration-max-queued-buffers{,-size} as the former is correctness fix
while the later are just additional functionalities.
ok. I have kept both patches in my tree with the doc updates.
I don't see the x-migration-load-config-after-iter patch in upstream QEMU
anywhere.
That's a bit concerning since it's a correctness fix - without it the
multifd VFIO migration on ARM64 can fail.
The existing patch still applies, but requires changing
"#if defined(TARGET_ARM)" to "strcmp(target_name(), "aarch64") == 0" due to
recent commit 5731baee6c3c ("hw/vfio: Compile some common objects once").
I can submit an updated patch if you like.
It is a bit early.
Let's wait for the spring cleanup to be applied first. I am waiting for
more feedback from Avihai and Joao. It should not be long.
I guess by "spring cleanup" you mean this patch set:
https://lore.kernel.org/qemu-devel/20250326075122.1299361-1-...@redhat.com/
It is marked "for-10.1" while I think we should not have this ARM64
regression in 10.0, which is due to be released in 2-3 weeks.
(The situation is different with the buffer queuing limits patches which
can wait since they are just additional functionalities rather than
correctness fixes).
Thanks,
C.
Thanks,
Maciej
