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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.12.18 at 12:45, <roger.pau@xxxxxxxxxx> wrote:
> 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.

Well, if we're _sure_ this can't happen, then of course we also
don't need to deal with it.

Jan



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