Re: [PATCH] migration: check magic value for deciding the mapping of channels

[Peter Xu]

Manish,

On Thu, Nov 03, 2022 at 11:47:51PM +0530, manish.mishra wrote:
> Yes, but if we try to read early on main channel with tls enabled case it is 
> an issue. Sorry i may not have put above comment cleary. I will try to put 
> scenario step wise.
> 1. main channel is created and tls handshake is done for main channel.
> 2. Destionation side tries to read magic early on main channel in 
> migration_ioc_process_incoming but it is not yet sent by source.
> 3. Source has written magic to main channel file buffer but it is not yet 
> flushed, it is flushed first time in ram_save_setup, i mean data is sent on 
> channel only if qemu file buffer is full or explicitly flushed.
> 4. Source side blocks on multifd_send_sync_main in ram_save_setup before 
> flushing qemu file. But multifd_send_sync_main is blocked for sem_sync until 
> handshake is done for multiFD channels.
> 5. Destination side is still waiting for reading magic on main channel, so 
> unless we return from migration_ioc_process_incoming we can not accept new 
> channel, so handshake of multiFD channel is blocked.
> 6. So basically source is blocked on multiFD channels handshake before 
> sending data on main channel, but destination is blocked waiting for data 
> before it can acknowledge multiFD channels and do handshake, so it kind of 
> creates a deadlock situation.

Why is this issue only happening with TLS?  It sounds like it'll happen as
long as multifd enabled.

I'm also thinking whether we should flush in qemu_savevm_state_header() so
at least upgraded src qemu will always flush the headers if it never hurts.

-- 
Peter Xu