[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/2019 14:37, Jan Beulich wrote:
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.
It is just an implementation detail. If I follow your view, we would have a
single header for everything under the same #ifdef...
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
