Re: [Xen-devel] [RFC PATCH 0/4] Per-domain locking in xl

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Wei Liu writes ("[RFC PATCH 0/4] Per-domain locking in xl"):
> It has always been the case that different xl processes can
> manipulate the same domain at the same time. This could be
> problematic.
> 
> This series attempts to provide facility for xl to have a per-domain
> lock. This lock should be used whenever xl manipulates an existing
> domain.

Unfortunately, this has to be done in a much more complicated way.

fcntl(,F_SETLKW,) is a `slow' function within the meaning of the
comment `Machinery for asynchronous operations ("ao")' at
libxl_internal.h:2100.

So acquisition of the guest lock needs to be done in callback style.
Since fcntl(,F_SETLKW,) is always synchronous, I think this may need
the use of fork or threads.  The owner of a fcntl lock is a process,
so fork won't do - but you could use flock, which is owned by an
open-file (and that would avoid threads).  If you do use fork you
should probably try F_SETLK first so that the fast path does not
involve forking.

Further observations:

We might well want new macros to help with the resulting boilerplate
in domain mutation initiators.

In general we would want to avoid explicit specification of the domid,
per se; rather we should pass a "locked-domain" object to any mutating
sub-functions.  Or we could put the locked-domain in the ctx or the
ao.  This needs further thought I think.

You need to clarify the status of the new lock in the lock hierarchy.
(When it was outside libxl, the lock hierarchy was implicit but
clear.)

The rules must forbid locking two guests at once, because of the
possibility of deadlock.  (An exception is migration: the destination
domain is created in locked state, so no deadlock is possible.)

We must consider how this interacts with stubdoms.  If a guest has a
stubdom, does the stubdom have its own lock ?  If so, what is the lock
order ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel