Kernel Design Questions re Paging

[purevoid]

Hi,

I've decided that the low layer of my kernel will need a complete redesign, and I have a few questions about implementation details.

The proposed system will have a single [kernel] address space, which both apps and kernel will run in. I was thinking of using 4MB superpages, but then I also want resizable stacks, and I think this might not work so well.

The idea is to use something like guard-pages at the end of the stack, and when the stack page-faults, I can allocate a larger stack, and resume execution. Would 4MB pages be ineffective for this sort of approach? Also, would this imply that the stack has to be multiples of the page size?

Additionally, even with paging, does the stack access virtual addresses or physical addresses? IE: is it possible that the physical addresses for the stack be non-contiguous?

I think that's everything covered... ;-)

[Colonel Kernel]

The idea is to use something like guard-pages at the end of the stack, and when the stack page-faults, I can allocate a larger stack, and resume execution. Would 4MB pages be ineffective for this sort of approach? Also, would this imply that the stack has to be multiples of the page size?

Yes, and yes. 4 MB pages would be very wasteful for stacks, since many stacks will consume less than 1 MB.

Additionally, even with paging, does the stack access virtual addresses or physical addresses? IE: is it possible that the physical addresses for the stack be non-contiguous?

Virtual addresses, and yes.

[AR]

Paging creates virtual address spaces simply by being turned on, as soon as paging is enabled ALL memory accesses are virtual and looked up in the page tables. Programs running on top of paging can't tell that paging is on (Reading CR0 is a priviledged operation) so no, the stack does not need to be physically contiguous.

[purevoid]

Okay, so my current idea is to do something like:

0 to 0x1000-1:
unmapped (apparently this should let me catch null pointer accesses)

0x1000 to 0x40_0000-1:
identity mapped 4k pages -- this should be usable for DMA right?

0x40_0000 to 3gig mark:
4MB pages, with kernel starting at 0x40_0000

3gig-4gig:
4k pages, where stacks would be allocated (also lets me set guard pages, so I can realloc stacks).

and then apps would be loaded in the first 3gig with the kernel, using a similar approach to linux kernel modules for loading them at runtime.

Does this sound feasible? And would the first 4MB of memory be suitable for all DMA transfers (though, I'm aware PCI devices don't have this restriction)?

Also, can I setup my kernel to be loaded into physical memory at the 4MB mark? And would GRUB boot this fine? (This would then imply that the first 8MB is identity mapped right? first half with 4k pages, second half with a single 4M page?).

PS: Sorry if I'm a bit verbose. I just want to get my kernel design right from the outset for once...