On 12/20/18 2:01 PM, Jan Beulich wrote: >> The practical implication of dom0 bias is that any hypercall which grabs >> two mm locks, one of two things must be true: >> * When it is called from one domU to another domU, locks must follow the >> "normal" locking order listed in mm-locks.h > > This would be a problem in the stubdom case.
Sure; but everything extends naturally from the 2-level case (dom0 / domU) to the 3-level case (dom0 / stubdom / domU). >> * When it is called between a dom0 and a domU, it must be consistenly >> called either one way or the other; i.e., it must always be dom0 calling >> it with a domU target, or domU calling it with a dom0 target (otherwise >> the dom0 / domU locking order is violated). > > Obviously (I hope) "domU calling it with a dom0 target" is an > uninteresting case, because we don't allow a domU to act on > dom0. Hence the consistency is achieved by it always going > to be "dom0 calling it with a domU target". We allow domU to send event channels to dom0, for instance; and presumably Argos allows domU to send things to dom0 as well as for dom0 to send things to domU. I don't know if those require the mm locks of both domains, but if they did, then we'd run into a problem again. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
