On Mon, Nov 04, 2024 at 06:02:33PM +0530, Prasad Pandit wrote:
> On Fri, 1 Nov 2024 at 20:04, Peter Xu <pet...@redhat.com> wrote:
> > As we discussed internally, we can't do this unconditionally. We at least
> > some compat properties.
>
> * ie. we define a new compat property to check if postcopy sends a
> magic value or not?
>
> > Or we need to see whether Fabiano's handshake can
> > simplify this, because the handshake will also re-design the channel
> > establishment protocol.
>
> * May I know more about this handshake change? Is there a repository?
> OR a page/document that describes what is being planned? Is it just
> channel establishment change or there's more to it?
After a 2nd thought, maybe we don't need a new compat property, and this
should work even before handshake ready.
Firstly, we'll need a way to tell mgmt that the new qemu binary supports
enablement of both multifd + postcopy feature. That can be done with a
"features": [ "postcopy-with-multifd-precopy" ]
Flag attached to the QMP "migrate" command.
Then, I think we don't need a magic for preempt channel, because new qemu
binaries (after 7.2) have no issue on out-of-order connections between main
/ preempt channel. Preempt channel is always connected later than main.
It means in the test logic of "which channel is which", it should be:
- If it's a multifd channel (check multifd header match), it's a multifd
channel, otherwise,
- if main channel is not present yet, it must be the main channel (and
we can double check the main channel magic), otherwise,
- it's the preempt channel
With that, I think we can drop the new magic sent here.
Thanks,
--
Peter Xu
