Hello Peter, On Mon, 15 Jul 2024 at 19:10, Peter Xu <pet...@redhat.com> wrote: > IMHO it's better we debug and fix all the issues before merging this one, > otherwise we may overlook something.
* Well we don't know where the issue is, not sure where the fix may go in, ex. if the issue turns out to be how virsh(1) invokes migrate-postcopy, fix may go in virsh(1). Patches in this series anyway don't help to fix the migration convergence issue, so they could be reviewed independently I guess. > You could pass over the patch to whoever going to debug this, so it will be > included in the whole set to be > posted when the bug is completely fixed. * Yes, this patch series is linked there. > The protocol should have no restriction on the thread model of a front-end. > It only describes the wire protocol. > > IIUC the protocol was designed to be serialized by nature (where there's no > request ID, so we can't match reply to any of the previous response), then > the front-end can manage the threads well to serialize all the requests, > like using this rwlock. * I see, okay. The simple protocol definition seems to indicate that it is meant for one front-end/back-end pair. If we are dividing the front-end across multiple threads, maybe we need a document to describe those threads and how they work, at least for the QEMU (front-end) side. Because the back-end could be a non-QEMU process, we can not do much there. (just thinking) Thank you. --- - Prasad
