Re: [Xen-devel] [PATCH] x86: fix paging_log_dirty_op to work with paging guests

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Dec 14, 2018 at 03:45:21AM -0700, Jan Beulich wrote:
> >>> On 14.12.18 at 11:03, <roger.pau@xxxxxxxxxx> wrote:
> > I expect the interdomain locking as a result of using a paging caller
> > domain is going to be restricted to the p2m lock of the caller domain,
> > as a result of the usage of copy to/from helpers.
> > 
> > Maybe the less intrusive change would be to just allow locking the
> > caller p2m lock (that only lock) regardless of the subject domain lock
> > level?
> 
> With caller != subject, and with the lock level then being higher
> than all "normal" ones, this might be an option. But from the
> very beginning we should keep the transitive aspect here in
> mind: If Dom0 controls a PVH domain which controls a HVM one,
> the Dom0 p2m lock may also need allowing to nest inside the PVH
> DomU's one, so it'll be a total of two extra new lock levels even
> if we restrict this to the p2m locks.

I'm not sure I follow here, so far we have spoken about a subject and
a caller domain (subject being the target of the operation). In the
above scenario I see a relation between Dom0 and the PVH domain, and
between the PVH domain and the HVM one, but not a relation that
encompasses the three domains in terms of mm locking.

Dom0 (caller) mm lock could be nested inside the PVH DomU (subject) mm
locks, and the PVH DomU (caller) locks could be nested inside the HVM
domain (subject) locks, but I don't see an operation where Dom0 mm
lock could be nested inside of a PVH DomU lock that's already nested
inside of the HVM DomU lock.

> 
> Furthermore, if we limited this to the p2m locks, it would become
> illegal to obtain any of the higher lock level locks (i.e. ones that
> nest inside the p2m lock) for the caller domain. I'm not sure
> that's a good idea. As mentioned before, if caller locks collectively
> all get obtained inside any subject domain ones, applying a bias
> to all lock levels would perhaps be preferable. The question is
> whether this criteria holds.

So far I can only think of paging callers requiring the p2m lock after
having locked an arbitrary number of subject domain mm locks in order
to perform the copy to/from of the operation data.

IMO a bias applied to caller locks when nested inside the subject
locks looks like the best solution.

> I also as of yet can't see how this could be expressed
> transparently to existing code. Yet obviously having to change
> various p2m_lock() invocations would be rather undesirable.

Most of the lock callers can be easily adjusted. Take p2m_lock for
example, the lock owner domain can be obtained from the p2m_domain
parameter (p2m_domain->domain) and this could be checked against
current->domain in order to figure out if the lock belongs to the
subject or the caller domain.

Thanks, Roger.

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