Hello,
On Wed, 19 Feb 2025 at 22:53, Fabiano Rosas <faro...@suse.de> wrote:
> I don't see anything stopping postcopy_start() from being called in the
> source in relation to multifd recv threads being setup in the
> destination. So far it seems possible that the source is opening the
> preempt channel while multifd still hasn't seen all threads. There's
> also pre-7.2 machines which create the postcopy channel early.
* If we can not predict the sequence/timings of when different types
of connections are initiated and processed, maybe source and
destination QEMUs could work in tandem. ie. before initiating a
connection, source QEMU could send an 'initiate' message saying I'm
initiating 'X' connection. Only when destination QEMU says 'okay',
source QEMU could proceed with actual connection.
QEMU-A -> Initiate connection type X -> QEMU-B
QEMU-A <- okay <- <- QEMU-B
QEMU-A -> connect type X -> QEMU-B
(thinking out loud)
>>> > * migration_needs_multiple_sockets()
>> Then it should return 'True' when both migrate_multifd() and
>> postcopy_preempt() are enabled.
> Why?
* I was thinking multiple_sockets is multiple types of sockets:
multifd & postcopy. But it seems here multiple sockets is any type of
multiple sockets.
> I thought you meant the CH_MAIN stuff. So now I don't know what you
> mean. You want to do away with multifd?
* Yes, CH_DEFAULT -> CH_MAIN was introduced in this series to identify
channels and accordingly call relevant functions.
* Not to do away with multifd, but more of making it same as the main
channel, ex: virsh migrate --threads <N> N = 1...255. All precopy
threads/connections behave the same. Differentiation of precopy and
postcopy shall still exist, because they operate/work in opposite
directions.
> Continue with this patch and fix the stuff I mentioned. You can ignore
> the first two paragraphs of that reply.
>
> https://lore.kernel.org/r/87y0y4tf5q....@suse.de
>
> I still think we need to test that preempt + multifd scenario, but it
> should be easy to write a test for that once the series is in more of a
> final shape.
* Okay.
> We can't add magic values, as we've discussed.
Okay.
Thank you.
---
- Prasad
