Thank you for pointing out my mistakes.....it helped to improve my understanding......and I have learned something!!! On Tue, May 6, 2008 at 1:53 AM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > On 05-05-08 18:03, Peter Teoh wrote: > > > > Specifically, if u cat /proc/iomem: > > > > /proc>cat iomem > > > > > e0000000-efffffff : PCI MMCONFIG 0 > > e0000000-efffffff : pnp 00:0e > > > > > And u can see that the 0xe000000 is occupied by someone else. > > > > Please be aware that /proc/iomem lists physical addresses, while his > request was for availability of a virtual address. > I was aware of the difference, that is why before I posted, I referred to LDD3, and found this mapping between /proc/*/maps (which is virtual address) and iomem. And since Greg in the book speaked as if the two address are the same (they are identical in the first place - could it be due to identity mapping for the low mem? I suspect so.....) and that's where I deduced that it is virtual memory. Here (the whole paragraph under "The mmap Device Operation"): http://people.freedesktop.org/~nagappan/LDD3/LDD3.html Ok...logically it should physical address....being IOMEM...and being process independent.... > The big problem with 0xe0000000 is that it's 512M into kernelspace on a > standard 32-bit architecture. > > Rene. > > Specifically zooming into the his last 512M (0xe0000000) thing, let's look at arch/x86/mm/init_32.c: mem_init() - the output is in dmesg: virtual kernel memory layout: fixmap : 0xffc54000 - 0xfffff000 (3756 kB) pkmap : 0xff400000 - 0xff800000 (4096 kB) vmalloc : 0xf8800000 - 0xff3fe000 ( 107 MB) lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) .init : 0xc0769000 - 0xc07a6000 ( 244 kB) .data : 0xc06344ed - 0xc0762ac0 (1209 kB) .text : 0xc0400000 - 0xc06344ed (2257 kB) And as mem_init() (arch/x86/mm/init_32.c) has partitioned the memory - the range that OP wanted was 0xe0000000 which in in the kernel virtual memory region, (as Rene has said), so definitely it is not allowed for userspace stack usage....which is what setup_arg_pages() is doing ---> per process userspace stack setup. And his "original 0xc0000000" is also in kernel range.....which is in the .text range of the kernel image.... but implementing userspace stack at 0xe000000 is also possible as well....first u have to reserve it early as in mem_init(), when multi-CPU is still not interferring each other....then u need to setup the pagetable for that mapping....and then setting the pageattributes labelling for the memory....technically and theoretically possible.....even better still is it technically possible to do this: if i am in kernel space....access 0xe000000 will immediate use one set of page table for it....and if in userspace....accessing 0xe000000 will immediately use another pagetable.....it can be confusing....but I think it can be done. A good analogy for this will be the 4g-4g split....lots of tlb flushing resulting in bad performance.....but just focusing on 0xe0000000 ...it may not be so bad..... Looking forward to sharing.....this is fun :-)..... -- 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
