Re: [Xen-devel] [PATCH] libxl: Documentation about the domain configuration on disk

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Wed, Dec 19, 2018 at 03:02:36PM +0000, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH] libxl: Documentation about the domain 
> configuration on disk"):
> > I think there is already a race, and `xl destroy` can leak QEMU. I've
> > called `xl create` with a sleep before spawn_local_dm, and during the
> > sleep, I call `xl destroy` with a sleep after it had an oportunity to
> > kill QEMU.  So we have:
> > 
> > 1 domain creation xc_domain_create
> > 2 domain destruction doesn't kill qemu, it's not there yet.
> > 3 domain creation spawn qemu
> > 4 domain creation creates libxl-json
> 
> I think the ordering of 3 vs 4 is a violation of my `thing' rules.
> This has gone unnoticed because we haven't been treating qemu itself
> as a `thing'.
> 
> If we did treat qemu itself as a Thing, it would be necessary to hold
> the libxl-json lock while forking it.  But fork is slow.
> 
> > > Maybe qemu's existence is `primary non-qmp state' and in fact domain
> > > destruction is not allowed to destroy it without holding the
> > > libxl-json lock.  But I bet that rule is not honoured right now.
> > 
> > I think it's fine for domain destruction to kill QEMU without any lock.
> > Any threads communicating via QMP should receive an error.
> 
> If qemu's existence is `primary qmp state' then the rules in my other
> mail imply holding the qmp lock for it while spawning it.  I think
> that would be doable ?

Yes, I think that can be done. And we can probably hold the lock from
just before spawning QEMU, until we have created libxl-json.

> > > Comments, anyone ?
> > 
> > That slow lock idea looks fine otherwise, we could call it
> > "libxl-qmp-lock" for now and have it mandatory when adding/removing
> > things via QMP. If a slow lock is needed for other thing than QMP, we
> > can change the meaning.
> 
> I don't mind calling it the `libxl qmp lock' in code or documentation,
> but the actual filename needs to not to be `libxl-qmp-lock' because we
> cannot easily change it later.  And there would be obvious advantages
> to making the name the same everywhere.
> 
> Anyway, I hope the above observations make sense to you.  Let me know
> what you think.

All those observations sounds good, I'll work on this new lock, try to
find a good name, and write some documentation on when it should be
hold.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel