On 4/2/25 14:40, Maciej S. Szmigiero wrote:
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.
A regression would be mean the feature worked before which is not case,
it didn't exist.
As said before, I'd rather expose the initial "multifd support for VFIO
migration" feature first without workarounds in QEMU 10.0.
Support on ARM is broken not because we are missing support in VFIO
but because there is an issue in the ordering of device states on ARM.
IMO, this needs to be addressed with a larger crowd. Please include
migration maintainers, the virt ARM maintainers, GIC maintainers and
let's see what can be done to avoid a workaround during the QEMU 10.1
cycle.
VFIO migration is a recent feature. VFIO migration support on ARM
(for MLX5 VFs) is even newer (there were recently fixes in the
upstream kernel for it). If a distro needs support for it, your
patch is there and ready to be backported. So there is a plan B.
Let's not rush things please.
Thanks,
C.
