All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: linux-mm <linux-mm@kvack.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Use of __pa() with CONFIG_NONLINEAR
Date: Tue, 27 Jul 2004 15:00:30 -0700	[thread overview]
Message-ID: <1090965630.15847.575.camel@nighthawk> (raw)

So, for CONFIG_NONLINEAR, we introduce a new indirection layer for
virtual to physical conversions (and the inverse as well).  Our
implementation uses some data structures to do this (patch is here:
http://lwn.net/Articles/79124/), and the side-effect is that we can't
use __pa() or __va() until after the initialization has run, which is
early in setup_arch().

But, there are quite a few things that obviously need physical addresses
earlier than that, such as cr3 initialization at compile-time.  So, in
Dave McCracken's patch, he introduced a new function: __boot_pa() that
does what the old __pa() did.

This is the largest and hardest to maintain part of the CONFIG_NONLINEAR
patch at this point, and I'd love to start merging bits of it back in. 
Would anybody object to a patch that just does this for a bunch of
architectures?

--- include/asm-i386/page.h.orig	2004-07-27 14:31:09.000000000 -0700
+++ include/asm-i386/page.h	2004-07-27 14:31:36.000000000 -0700
@@ -128,8 +128,10 @@ static __inline__ int get_order(unsigned
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
 #define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
-#define __pa(x)			((unsigned long)(x)-PAGE_OFFSET)
-#define __va(x)			((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __boot_pa(x)		((unsigned long)(x)-PAGE_OFFSET)
+#define __boot_va(x)		((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __pa(x)			__boot_pa(x)
+#define __va(x)			__boot_va(x)
 #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)
 #ifndef CONFIG_DISCONTIGMEM
 #define pfn_to_page(pfn)	(mem_map + (pfn))

We will, of course be overriding __{v,p}a() for any architectures that
we do nonlinear with, later on.

The only other thing I can think of is to make __pa() effectively the
boot-time, simple one, and make virt_to_phys() the more sophisticated
one that we override with nonlinear.  But, some architectures '#define
__pa() virt_to_phys()', while others do the opposite, so that approach
could be significantly more work.  

Does anybody really remember what the different between the __{p,v}a()
functions and the virt_to_phys() ones is supposed to be?

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: linux-mm <linux-mm@kvack.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Use of __pa() with CONFIG_NONLINEAR
Date: Tue, 27 Jul 2004 15:00:30 -0700	[thread overview]
Message-ID: <1090965630.15847.575.camel@nighthawk> (raw)

So, for CONFIG_NONLINEAR, we introduce a new indirection layer for
virtual to physical conversions (and the inverse as well).  Our
implementation uses some data structures to do this (patch is here:
http://lwn.net/Articles/79124/), and the side-effect is that we can't
use __pa() or __va() until after the initialization has run, which is
early in setup_arch().

But, there are quite a few things that obviously need physical addresses
earlier than that, such as cr3 initialization at compile-time.  So, in
Dave McCracken's patch, he introduced a new function: __boot_pa() that
does what the old __pa() did.

This is the largest and hardest to maintain part of the CONFIG_NONLINEAR
patch at this point, and I'd love to start merging bits of it back in. 
Would anybody object to a patch that just does this for a bunch of
architectures?

--- include/asm-i386/page.h.orig	2004-07-27 14:31:09.000000000 -0700
+++ include/asm-i386/page.h	2004-07-27 14:31:36.000000000 -0700
@@ -128,8 +128,10 @@ static __inline__ int get_order(unsigned
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 #define VMALLOC_RESERVE		((unsigned long)__VMALLOC_RESERVE)
 #define MAXMEM			(-__PAGE_OFFSET-__VMALLOC_RESERVE)
-#define __pa(x)			((unsigned long)(x)-PAGE_OFFSET)
-#define __va(x)			((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __boot_pa(x)		((unsigned long)(x)-PAGE_OFFSET)
+#define __boot_va(x)		((void *)((unsigned long)(x)+PAGE_OFFSET))
+#define __pa(x)			__boot_pa(x)
+#define __va(x)			__boot_va(x)
 #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)
 #ifndef CONFIG_DISCONTIGMEM
 #define pfn_to_page(pfn)	(mem_map + (pfn))

We will, of course be overriding __{v,p}a() for any architectures that
we do nonlinear with, later on.

The only other thing I can think of is to make __pa() effectively the
boot-time, simple one, and make virt_to_phys() the more sophisticated
one that we override with nonlinear.  But, some architectures '#define
__pa() virt_to_phys()', while others do the opposite, so that approach
could be significantly more work.  

Does anybody really remember what the different between the __{p,v}a()
functions and the virt_to_phys() ones is supposed to be?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

             reply	other threads:[~2004-07-27 22:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-27 22:00 Dave Hansen [this message]
2004-07-27 22:00 ` Use of __pa() with CONFIG_NONLINEAR Dave Hansen
2004-07-28 16:20 ` Joel Schopp
2004-07-28 16:20   ` Joel Schopp
2004-07-28 18:16 ` Mike Kravetz
2004-07-28 18:16   ` Mike Kravetz
2004-07-28 19:47   ` Martin J. Bligh
2004-07-28 19:47     ` Martin J. Bligh
2004-07-28 20:13     ` Dave Hansen
2004-07-28 20:13       ` Dave Hansen
2004-07-28 20:15       ` Martin J. Bligh
2004-07-28 20:15         ` Martin J. Bligh
2004-07-28 20:23         ` Dave Hansen
2004-07-28 20:23           ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1090965630.15847.575.camel@nighthawk \
    --to=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.