< My Design - this model is not final by any means, I will change this model when I write the multitasking features. >
(Physical Memory Manager) (Kernel Virtual Memory Manager)
I. Boot Steps
1. Boot Loader (loads the Kernel Image. The Kernel Image consists of two parts, Kernel Loader/Kernel.)
2. Kernel Loader (enables Long Mode and relocates the Kernel, maps the Kernel at high area-0xFFFF800000000000, for an initial structure, the low 1-MB memory is mapped at 0x0~0xFFFFF, and the kernel is mapped at 0xFFFF800000000000-0xFFFF8000003FFFFF).
3. Kernel
II. Kernel Initialisation Procedure
1. Initialisation of the Kernel Virtual Memory Manager (creates a new paging structure that is managed by the kernel, maps 32MB at 0xFFFF800000000000 for the kernel, maps the low 1-MB area at high area- 0xFFFFFFFFFFF00000).
2. Initialisation of the Physical Memory Manager (PMM manages the physical memory area to determine whether a specific physical memory block is used).
Issues
1. Getting the physical memory size after the Long Mode is enabled: paging is mandatory in long mode. For this reason, it is necessary to map a physical page for brute-force scanning. For example, map Page 0 (VA 0x0~0xFFF) to 0x100000 and test, map 0x200000 and test, and so on). Is there a better way of doing this?
2. It is necessary to construct a physical memory allocation table for the Physical Memory Manager, where each allocation entry must keep track of the page allocation count for shared memory feature. I decided to make each entry 4 bytes long and, if the physical memory is 512GB, this would render the Physical Memory Allocation Table size to be 512 MB (1024*1024*1024*512/4096*4/1024/1024), which is bigger than initial map space 32MB. Is there a solution for this?
A question about EM64T Memory Management
A question about EM64T Memory Management
Last edited by stephanos on Fri Apr 29, 2016 8:32 pm, edited 1 time in total.
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: A question about EM64T Memory Management
1. Use multiboot memory map or int 15h eax=E820h bios function (which are effectively the same). Testing memory is a bad idea, you'll probably screw up some devices and detect memory that doesn't actually exist. See the wiki.
2. I recommend using a page frame table that records whether a page frame is mapped and where it is mapped. You can create a page frame table for each memory region you get from the multiboot memory map / int 15h eax=E820h. And mapping all memory with large pages is a bad idea, because it interferes with cache control. Map memory as you use it.
3. Don't worry about it
I recommend doing all initialization in your kernel loader, and using identity mapping in the kernel loader to simplify everything.
2. I recommend using a page frame table that records whether a page frame is mapped and where it is mapped. You can create a page frame table for each memory region you get from the multiboot memory map / int 15h eax=E820h. And mapping all memory with large pages is a bad idea, because it interferes with cache control. Map memory as you use it.
3. Don't worry about it
I recommend doing all initialization in your kernel loader, and using identity mapping in the kernel loader to simplify everything.
Re: A question about EM64T Memory Management
stephanos wrote:nd the kernel is mapped at 0xFFFF800000000000-0xFFFF8000003FFFFF
Linear address is limited to either 52 or 48 (might be less) bits. Use CPUID to figure out max range of linear address.
Re: A question about EM64T Memory Management
exkor wrote:stephanos wrote:nd the kernel is mapped at 0xFFFF800000000000-0xFFFF8000003FFFFF
Linear address is limited to either 52 or 48 (might be less) bits. Use CPUID to figure out max range of linear address.
Is there already 52-bit canonical address supportment?
I thought that there was only one form of canonical address that is currently supported, 48-bit form which uses PML4 Table entry 0~255 for Low Map, 256~511 for High Map).
Re: A question about EM64T Memory Management
I think I got the answer. Thank you.JohnnyTheDon wrote:1. Use multiboot memory map or int 15h eax=E820h bios function (which are effectively the same). Testing memory is a bad idea, you'll probably screw up some devices and detect memory that doesn't actually exist. See the wiki.
2. I recommend using a page frame table that records whether a page frame is mapped and where it is mapped. You can create a page frame table for each memory region you get from the multiboot memory map / int 15h eax=E820h. And mapping all memory with large pages is a bad idea, because it interferes with cache control. Map memory as you use it.
3. Don't worry about it
I recommend doing all initialization in your kernel loader, and using identity mapping in the kernel loader to simplify everything.
Last edited by stephanos on Fri Apr 29, 2016 8:22 pm, edited 1 time in total.
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: A question about EM64T Memory Management
stephanos wrote:exkor wrote:stephanos wrote:nd the kernel is mapped at 0xFFFF800000000000-0xFFFF8000003FFFFF
Linear address is limited to either 52 or 48 (might be less) bits. Use CPUID to figure out max range of linear address.
Is there already 52-bit canonical address supportment?
I thought that there was only one form of canonical address that is currently supported, 48-bit form which uses PML4 Table entry 0~255 for Low Map, 256~511 for High Map).
AFAIK thats all there is right now. However, there might be something in the future, like a super PAE mode, that adds another mapping level or something like that.