early, early ioremap
PATCH 1/1 early, early ioremap
Because of some braindead hardware engineers, we need to map in some high memory areas just to find out how much memory we have, and where it is. (the e820 table doesn't cut it on this hardware)
I can't think of a good name for this. It's earlier than bt_ioremap() and super_mega_bt_ioremap() doesn't have much of a ring to it.
This is only intended for remapping while the boot-time pagetables are still in use. It was a pain to get the 2-level pgtable.h functions, so I just undef'd CONFIG_X86_PAE for my file. It looks awfully hackish, but it works well.
Some of my colleagues prefer to steal ptes from some random source, then replace them when the remapping is done, but I don't really like this approach. I prefer to know exactly where I'm stealing them from, which is where boot_ioremap_area[] comes in.
Signature · 2 lines
Dave Hansen [email protected]
arch/i386/mm/Makefile +1 -1
@@ -4,7 +4,7 @@ export-objs := pageattr.o -obj-y := init.o pgtable.o fault.o ioremap.o extable.o pageattr.o +obj-y := init.o pgtable.o fault.o ioremap.o extable.o pageattr.o boot_ioremap.o obj-$(CONFIG_DISCONTIGMEM) += discontig.o obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
arch/i386/mm/boot_ioremap.c +94 -0
94 lines not on this page · raw message
include/asm-i386/page.h +1 -0
@@ -49,6 +49,7 @@typedef struct {unsigned long pte_low; }pte_t ;typedef struct {unsigned long pmd; }pmd_t ;typedef struct {unsigned long pgd; }pgd_t ; +#define boot_pte_t pte_t/* or would you rather have a typedef */ #define pte_val (x) ((x).pte_low)#define HPAGE_SHIFT 22#endif
Quoted 12 lines
Because of some braindead hardware engineers, we need to map in some high memory areas just to find out how much memory we have, and where it is. (the e820 table doesn't cut it on this hardware)
I can't think of a good name for this. It's earlier than
bt_ioremap()andsuper_mega_bt_ioremap()doesn't have much of a ring to it.This is only intended for remapping while the boot-time pagetables are still in use. It was a pain to get the 2-level
pgtable.hfunctions, so I just undef'dCONFIG_X86_PAEfor my file. It looks awfully hackish, but it works well.
Quoted 4 lines
Some of my colleagues prefer to steal ptes from some random source, then replace them when the remapping is done, but I don't really like this approach. I prefer to know exactly where I'm stealing them from, which is where boot_ioremap_area[] comes in.
OK, rather than "some random source", how about we designate the window from 7Mb - 8Mb as the early vmalloc space (akin to __VMALLOC_RESERVE), and use that for early kmap / set_fixmap / whatever. I think that's better than the array allocated from kernel data segment.
Either a per-page bitmap of used areas, a fixmap-type array, or simply making the user keep track of it would be fine ...
Opinions?
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]">[email protected]</a>
Quoted 4 lines · Martin J. Bligh
Either a per-page bitmap of used areas, a fixmap-type array, or simply making the user keep track of it would be fine ...
Opinions?
Why not use an early kmap_atomic()? It's easy enough to enable the code on a non-highmem build as you would need for this purpose. Also, making atomic kmaps able to map io space could be useful to replace ACPI's kludge too.
-ben
Signature · 6 lines
Don't email: <a href=mailto:"[email protected]">[email protected]</a> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"[email protected]">[email protected]</a>