Re: [Xen-devel] [PATCH v7 01/12] x86/mm: allow a privileged PV domain to map guest mfns

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/09/17 14:02, Jan Beulich wrote:
>>>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
>> In the case where a PV domain is mapping guest resources then it needs make
>> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
>> domid, so that the passed in gmfn values are correctly treated as mfns
>> rather than gfns present in the guest p2m.
> Since things are presently working fine, I think the description is not
> really accurate. You only require the new behavior if you don't know
> the GFN of the page you want to map, and that it has to be
> DOMID_SELF that should be passed also doesn't appear to derive
> from anything else. To properly judge about the need for this patch
> it would help if it was briefly explained why being able to map by GFN
> is no longer sufficient, and to re-word the DOMID_SELF part.

I think there is still confusion as to the purpose here.

For security and scalability reasons, we explicitly want to be able to
create frames which are not part of a guests p2m.  We still need to map
these frames however.

The frames are referred to in an abstract way by a space id/offset.  To
create mappings of these frames, PV guests pass an array which Xen fills
in with MFNs, while HVM guests pass an array of GFNs which have their
mappings updated.

The problem is trying to map an MFN belonging to a target domain,
because Xen interprets the frame under the targets paging mode.  Passing
DOMID_SELF here is Pauls way of getting Xen to interpret the frame under
current's paging mode.

Alternative suggestions welcome.

~Andrew

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