On 01/14/18 00:30, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote:
On 01/13/18 15:28, Nathan Whitehorn wrote:
On 01/13/18 15:24, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 11:14:53PM +0000, Nathan Whitehorn wrote:
+/*
+ * We (usually) have a direct map of all physical memory. All
+ * uses of this macro must be gated by a check on hw_direct_map!
+ * The location of the direct map may not be 1:1 in future, so use
+ * of the macro is recommended; it may also grow an assert that
hw_direct_map
+ * is set.
+ */
+#define PHYS_TO_DMAP(x) x
+#define DMAP_TO_PHYS(x) x
Take a look at the sys/vm/vm_page.c:vm_page_free_prep() function.
I think the checks in there should work as designed, unless I'm
missing something. Am I?
-Nathan
Actually, wait, this is broken if hw_direct_map is not set. I can do an
#ifdef __powerpc__ hack, but do you have opinions for a better MI flag
for "yes, the macro is defined but, no, the direct map may not be
available"?
Exactly. You explicitly noted the need to check for the hw_direct_map
in the comment, so I did not see a need to explain further.
We intended that PHYS_TO_DMAP/DMAP_TO_PHYS become MI KPI. If the symbols
are present, their semantic is the unconditional presence and usability of
the direct map.
sf bufs were rototiled with things like SFBUF_OPTIONAL_DIRECT_MAP, but I
dislike it and hope that PHYS_TO_DMAP would be not damaged this way.
That's unfortunate. Is there any reason you need this to be certain at
compile time? That seems to be quite restrictive and not to add a huge
amount of performance. Given the exciting variety of MMU modes on
PowerPC, there is not any way to guarantee the presence of a direct map
at compile time, so the alternative is to invent a whole new kernel
signalling mechanism for "direct map is almost certainly available, but
might not be", which seems strictly worse, or to have a standard API
that PowerPC can't use, which also seems worse.
-Nathan
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
