On 21/10/22 3:37 am, Daniel P. Berrangé wrote:
On Thu, Oct 20, 2022 at 12:32:06PM -0400, Peter Xu wrote:
On Thu, Oct 20, 2022 at 08:14:19PM +0530, manish.mishra wrote:
I had one concern, during recover we do not send any magic. As of now we
   do not support multifd with postcopy so it should be fine, we can do
   explict checking for non-recovery case. But i remember from some
   discussion in future there may be support for multiFD with postcopy or
   have multiple postcopy preempt channels too, then proper handshake will
   be required? So at some point we want to take that path? For now i agree
   approach 1 will be good as suggested by Daniel it can be backported
   easily to older qemu's too.

Yes for the long run I think we should provide a generic solution for all
the channels to be established for migration purpose.

Not to mention that as I replied previously to my original email, the trick
won't easily work with dest QEMU where we need further change to allow qemu
to accept new channels during loading of the VM.

Considering the complexity that it'll take just to resolve the prempt
channel ordering, I think maybe it's cleaner we just look for the long term
goal.
I think we should just ignore the preempt channel. Lets just do the
easy bit and fix the main vs multifd channel mixup, as that's the one
that is definitely actively hitting people today. We can solve that as
a quick win in a way that is easy to backport to existing releases of
QEMU for those affected.
Yes, that works for now Daniel. I can send a patch as per your earlier 
suggestions on this, early next week if it fine?
Separately from that, lets define a clean slate migration protocol to
solve many of our historic problems and mistakes that can't be dealt
with through retrofitting, not limited to just this ordering mistake.

We had a significant discussion about it at the start of the year
in this thread, which I think we should take forward and write into
a formal protocol spec.

   
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.gnu.org_archive_html_qemu-2Ddevel_2022-2D03_msg03655.html&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=c4KON2DiMd-szjwjggQcuUvTsPWblztAL0gVzaHnNmc&m=vjRKUpojJeAWFcJNi7YETWaLjjOcLWIcdk8KO-HMu8_A3veG2aaGmZoLxFVHgLt0&s=uv5cKdIMcT8Wo3erYQZJqnMXvRCbda4gNtxsy9EXrC8&e=
This was a good read for me. :)

With regards,
Daniel

Thanks

Manish Mishra


Reply via email to