[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 25.09.17 at 15:29, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

In the course of reviewing patch 2 I've gained some more
understanding of the intentions. Still it would have been
helpful to have an abstract understanding already before even
looking at patch 1, i.e. presented in the overview mail.

> 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.

I've given one in the earlier reply.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.