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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.17 at 16:42, <Paul.Durrant@xxxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 25 September 2017 14:03
>> >>> On 18.09.17 at 17:31, <paul.durrant@xxxxxxxxxx> wrote:
>> The other aspect I don't understand is why this is needed for PV
>> Dom0, but not for PVH. The answer here can't be "because PVH
>> Dom0 isn't supported yet", because it eventually will be, and then
>> there will still be the problem of PVH supposedly having no notion
>> of MFNs (be their own or foreign guest ones). The answer also
>> can't be "since it would use XENMAPSPACE_gmfn_foreign", as
>> that's acting in terms of GFN too.
> 
> The hypercall is PV-only. For a PVH/HVM tools domain things are handled by 
> doing an add-to-physmap to gfns specified by the tools domain. I have tested 
> both PV and HVM clients of my new memory op.

And how is this add-to-physmap any better superpage shattering
wise than the old mechansim?

>> > -        if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
>> > +        if ( (real_pg_owner == NULL) ||
>> >               xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
>> >          {
>> >              gdprintk(XENLOG_WARNING,
>> 
>> I'm concerned of the effect of the change on the code paths
>> which you're not really interested in: alloc_l1_table(),
>> ptwr_emulated_update(), and shadow_get_page_from_l1e() all
>> explicitly pass both domains identical, and are now suddenly able
>> to do things they weren't supposed to do. A similar concern
>> applies to __do_update_va_mapping() calling mod_l1_table().
>> 
>> I therefore wonder whether the solution to your problem
>> wouldn't rather be MMU_FOREIGN_PT_UPDATE (name subject
>> to improvement suggestions). This at the same time would
>> address my concern regarding the misleading DOMID_SELF
>> passing when really a foreign domain's page is meant.
> 
> Ok. I'm not familiar with MMU_FOREIGN_PT_UPDATE so I'd need to investigate. 
> I just need a mechanism for a privileged PV guest to map pages belonging to 
> another guest that don't appear in that guests P2M. As I said above, it's 
> much simpler if the tools domain is PVH or HVM.

Hmm, looks like I wasn't able to express things such that it
becomes clear the MMU_FOREIGN_PT_UPDATE is the proposed
(sub-optimal) name for a new sub-op.

Jan


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