[libvirt] [PATCH] create a thread to handle MigrationParamResetto avoid deadlock

[wang.yi59 at zte.com.cn]

Hi Daniel,

Thanks a lot for your review and reply!

> On Mon, Dec 23, 2019 at 04:50:00PM +0100, Michal Prívozník wrote:
> > On 12/23/19 11:12 AM, Daniel P. Berrangé wrote:
> > > On Mon, Dec 23, 2019 at 03:13:10PM +0800, Yi Wang wrote:
> > >> From: Li XueLei <li.xuelei1 at zte.com.cn>
> > >>
> > >> Libvirtd no longer receives external requests, after I do the following.
> > >>

.....

> > >
> > > Libvirt allows multiple connections concurrently and changes made by one
> > > connection are supposed to apply globally. No per-VM state should be tied
> > > to a particular connection.
> >
> > This is generally very true, except for migration.
>
> Hmm, so in that case we do need to make sure this runs from a non-main
> event thread as this patch does. I'm surprised we've not seen this
> before though - i'd think it should be a guaranteed deadlock anytime
> someone tests this scenario.
>
> >
> > >
> > > IOW, I don't think we need a thread. We should just stop calling
> > > qemuMigrationSrcCleanup from the connection close callback entirely
> >
> > But I agree that something fishy is going on and this doesn't look like
> > proper solution. Yi, can you please share the backtrace of other threads
> > too? Why aren't we getting any reply on the monitor?
>
> qemuMonitorSend() just puts date onto the TX queue & waits for the
> main event loop to send it.  We're invoking qemuMonitorSend from
> the main event loop in this backtrace, hence it'll wait forever
> for the thread to send it.
>
> qemuMonitorSend must never be invoked from the main event thread.

So do you think how to imporve this patch? Any sugesstion is appreciated :-)

>
> Regards,
> Daniel