[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |