Re: [Xen-devel] [PATCH 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.05.19 at 15:29, <julien.grall@xxxxxxx> wrote:
> On 10/05/2019 14:28, Jan Beulich wrote:
>>>>> On 07.05.19 at 17:14, <julien.grall@xxxxxxx> wrote:
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -658,4 +658,18 @@ static inline void 
>>> share_xen_page_with_privileged_guests(
>>>       share_xen_page_with_guest(page, dom_xen, flags);
>>>   }
>>>   
>>> +/*
>>> + * Dummy implementation of M2P-related helpers for common code when
>>> + * the architecture doesn't have an M2P.
>>> + */
>>> +#ifndef CONFIG_HAS_M2P
>>> +
>>> +#define INVALID_M2P_ENTRY        (~0UL)
>>> +#define SHARED_M2P_ENTRY         (~0UL - 1UL)
>>> +#define SHARED_M2P(_e)           ((_e) == SHARED_M2P_ENTRY)
>>> +
>>> +static inline void set_pfn_from_mfn(mfn_t mfn, unsigned long pfn) {}
>>> +
>>> +#endif
>> 
>> In order for things to not be scattered around, could
>> domain_shared_info_gfn() (see patch 9) move here? It doesn't
>> look as if this would cause a build issue.
> 
> The two are different, one deal with memory, the other with a domain. So the 
> current split makes sense.

Well, that's one perspective to take. The other is that it's mm to obtain
a specific other form of a given address.

Jan



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