Thank you Mulyadi,
On Sat, Jun 14, 2008 at 10:41 PM, Mulyadi Santosa
<mulyadi.santosa@xxxxxxxxx> wrote:
> Hi!
>
> On Sat, Jun 14, 2008 at 12:48 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
>> In setup_arch() I saw:
>>
>> paging_init();
>>
>> /*
>> * NOTE: On x86-32, only from this point on, fixmaps are ready for use.
>> */
>>
>> What is the meaning of "fixmaps" as I saw it occasionally used in kernel source?
>
> sounds like "fixed mapping"..... area defined somewhere inside vmalloc
> reserved virtual address range...IIRC they are for things like atomic
> mapping...I can't recall the exact meanings...
>
Looking at dmesg:
Memory: 2073244k/2096704k available (2259k kernel code, 22276k
reserved, 1271k data, 272k init, 1179200k highmem)
virtual kernel memory layout:
fixmap : 0xffc58000 - 0xfffff000 (3740 kB)
pkmap : 0xff400000 - 0xff800000 (4096 kB)
vmalloc : 0xf8800000 - 0xff3fe000 ( 107 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc0779000 - 0xc07bd000 ( 272 kB)
.data : 0xc0634e86 - 0xc0772c80 (1271 kB)
.text : 0xc0400000 - 0xc0634e86 (2259 kB)
And the source setup_32.c print it as:
FIXADDR_START, FIXADDR_TOP,
(FIXADDR_TOP - FIXADDR_START) >> 10,
#ifdef CONFIG_HIGHMEM
PKMAP_BASE, PKMAP_BASE+LAST_PKMAP*PAGE_SIZE,
(LAST_PKMAP*PAGE_SIZE) >> 10,
#endif
VMALLOC_START, VMALLOC_END,
(VMALLOC_END - VMALLOC_START) >> 20,
Therefore, it is quite identical for all x86 machines. and according
to a patch:
The fixmap code from x86 allows us to have compile time virtual addresses
that we change the physical addresses of at run time.
====>So which means is that compile time we can FIX the virtual address.
This is useful for applications like kmap_atomic, PCI config that is done
via direct memory map, kexec/kdump.
====>And I think Eric explained his reason for creating/using the fixmap here:
http://lkml.org/lkml/2006/12/4/5
To use the debug device I need to work through a port so I need
to call ioreamp or similar. Since we are doing this very early
I chose to use a fixmap (because we are unlikely to free the mapping)
and because it is simple. If we preallocate the fixmap pud and pmd
entries the existing fixmap codes works anytime from power up without
modifications or memory allocations. So we don't need a special case.
Another angle of analysis (from http://lkml.org/lkml/2005/8/5/323):
* Zachary Amsden (zach@xxxxxxxxxx) wrote:
> This most curious patch allows the fixmap on i386 to be unfixed. The
> result is that we can create a dynamically sizable hole at the top of
> kernel linear address space. I know at least some virtualization
> developers are interested in being able to achieve this to achieve
> run-time sizing of a hole in which a hypervisor can live, or at least to
> test out the performance characteristics of different sized holes.
I've done it simpler with keeping it fixed but defined by the subarch.
Patch is stupid simple (and untested). Do you think there's a huge gain
for dynamically sizing?
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xfffff000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+ FIX_VSYSCALL,
+#ifdef CONFIG_X86_LOCAL_APIC
+ FIX_APIC_BASE, /* local (CPU) APIC) -- required for SMP or not */
+#endif
+#ifdef CONFIG_X86_IO_APIC
+ FIX_IO_APIC_BASE_0,
+ FIX_IO_APIC_BASE_END = FIX_IO_APIC_BASE_0 + MAX_IO_APICS-1,
+#endif
+#ifdef CONFIG_X86_VISWS_APIC
+ FIX_CO_CPU, /* Cobalt timer */
+ FIX_CO_APIC, /* Cobalt APIC Redirection Table */
+ FIX_LI_PCIA, /* Lithium PCI Bridge A */
+ FIX_LI_PCIB, /* Lithium PCI Bridge B */
+#endif
+#ifdef CONFIG_X86_F00F_BUG
+ FIX_F00F_IDT, /* Virtual mapping for IDT */
+#endif
+#ifdef CONFIG_X86_CYCLONE_TIMER
+ FIX_CYCLONE_TIMER, /*cyclone timer register*/
+#endif
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+#ifdef CONFIG_ACPI_BOOT
+ FIX_ACPI_BEGIN,
+ FIX_ACPI_END = FIX_ACPI_BEGIN + FIX_ACPI_PAGES - 1,
+#endif
+#ifdef CONFIG_PCI_MMCONFIG
+ FIX_PCIE_MCFG,
+#endif
+ __end_of_permanent_fixed_addresses,
+ /* temporary boot-time mappings, used before ioremap() is functional */
+#define NR_FIX_BTMAPS 16
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS - 1,
+ FIX_WP_TEST,
+ __end_of_fixed_addresses
+};
Notice the long list of enum --> fixed_addresses, which also described
its various usage within the fixmap.
Thanks.
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
