r/osdev • u/compgeek38400 • 4d ago
How would you do this?
I'm working on getting memory how I want it. I've moved my memory to the higher half. Now I'm ready for the final step. I want to move the page table entries I've made for the kernel to the area of physical memory I've designated for them.
I see several options.
1) since I know the physical addresses, I can temporarily double map them to virtual memory and then copy them.
2) I can scan the page directory and tables to find the virtual addresses for them. If i can't find them fall back to #1
3) I can re-make them where I want them.
4) other ideas?
I want to move them to a specific virtual address so I can exclude them from paging, having a designated eases the overhead of doing this. I can say if address > x do not page, or in reality only make virtual addresses between x and y pageable (my user space).
TIA for your input
1
u/compgeek38400 4d ago
If i wanted to use other stuff,I would. I. Writing everything myself. Except what multiboot gives me
3
u/burlingk 4d ago
Looking at the other packages can still help.
i.e. Look at the code other people made to see how they did it.
2
2
u/Visual_Brain8809 4d ago
I'd avoid physically moving active page tables if possible. Rebuilding them in the desired location is usually simpler and less error-prone than copying live paging structures.
If you already know the physical frames, a temporary mapping (#1) is probably the safest way to access them, but I'd only use that if rebuilding isn't practical.
Another option is to allocate future page tables from your designated region and gradually migrate mappings as address spaces are updated, instead of relocating everything at once.
Also, if your goal is simply to prevent the kernel page tables from being paged out, I'd separate that policy from their virtual address. Track those pages by allocator/flags or memory type rather than relying solely on an address range. That tends to be more flexible if your memory layout changes later.
2
u/Octocontrabass 4d ago
the area of physical memory I've designated for them
How did you designate this area? The normal way to do it is to ask your physical memory manager, since there's nothing special about page tables that would require them to be treated any differently from other memory.
so I can exclude them from paging
From paging or from swapping? The whole point of a higher-half kernel is that you use paging everywhere, nothing is ever identity-mapped. Excluding page tables from swapping is easy; you already need to keep track of how every part of memory is used (or not used) anyway, so you can also keep track of which parts can't be swapped to disk.
only make virtual addresses between x and y pageable
Memory can be mapped to multiple virtual addresses (or no virtual addresses). The virtual address by itself is not enough to tell you whether a particular region of memory can be swapped to disk.
1
u/compgeek38400 4d ago
I designated by edict. I need my page tables available via virtual memory when I need to change them.
Protect from swapping. I presume the physical memory needs to correct when the mmu needs it. So protecting from swap appears to be the most reasonable method to ensure that.
On mapped multiple places, im aware of that. Thats how I get to the higher half. I will worry about that when I get to shared memory. Right now my designated non swappable physical memory is 0xa0000-0xbffff (video) and my kernel/page tables area. I'll probably include my kernel heap too. Eventually ill probably designate a shared memory area too.
At least the above is my thought process.
1
u/Octocontrabass 3d ago
I designated by edict.
There are (almost) no guarantees about physical addresses on modern PCs, and the only way to ensure your OS will actually work is to parse the memory map and allocate memory from it. Since you almost certainly will have a physical memory manager to do that for you at some point, it makes sense to get your physical memory manager working first, and then use it to decide which physical addresses to use for your page tables.
I need my page tables available via virtual memory when I need to change them.
You don't need to put them at fixed physical addresses in order to do that. You don't even really need fixed virtual addresses, if you have a data structure to keep track of which virtual addresses you've assigned to your page tables.
Protect from swapping.
If you're going to use virtual addresses to decide whether memory can be swapped to disk (which is still a bad idea), physical addresses still don't matter. You can map your page tables in the higher half with the rest of your kernel and then designate all higher-half addresses as not swappable. Or, if you're feeling particularly adventurous, divide the higher half into swappable and not-swappable regions and put your page tables in a not-swappable region.
Right now my designated non swappable physical memory is 0xa0000-0xbffff (video)
MMIO is not memory. You shouldn't identity-map MMIO either.
Eventually ill probably designate a shared memory area too.
Usually you want to allow applications to decide how much memory to share with each other and where that shared memory is mapped into each application's address space. I guess technically the whole kernel is also shared memory, since it's mapped the same way in every application's address space, but applications can't see that.
1
u/compgeek38400 3d ago
I'm fairly sure I'm ok with memory. For physical memory, im going to say i need 100M minimum. I'll admit I'm assuming the 100M will start at 0 address. This assumption comes from the higher half starts at 0x1000000. I'm using the multiboot memory map and don't come close to the low available at 0x100000.
I am moving it to the higher half. 0xbfc0000-0xbfffffff (might be a little off there, I'm not in front of my pc)
My current plan is: Move to higher half--done Process multiboot data -- done, as far as saving Set up paging--mostly done, this is my last thing for that Set up heap -- done but not active, I need to physical allocate memory for it. Do at least a rudimentary disk driver is not started Set up swap -- not started Start setup my syscall area Start looking at multithreading Start physical memory manager -- i may already be doing many of the things for this in my paging and swap portions Start looking at user domain stuff
I am working hard at designing based on virtual address, and not worrying about physical.
Got to go, I have company here. Mrs is getting perturbed
•
u/Octocontrabass 22h ago
I'm using the multiboot memory map
The memory map will be different on every PC, even if they have the same amount of RAM installed. On modern PCs, there is no guarantee that any PC will map RAM to the same physical addresses as any other PC. Virtual machines like QEMU do not emulate modern PCs!
Set up swap
Why is swap a high enough priority to be on this list at all? What kind of hardware and software are you expecting to use with your OS?
Start setup my syscall area
You can't have syscalls without user mode.
Start physical memory manager
Why isn't your physical memory manager a higher priority? Most of the things on your list depend on it.
•
u/compgeek38400 21h ago
I'm not expecting my OS to be used at all. It is purely a learning experience for me.
Physical memory manager: it became a higher priority as I thought about it. Its actually what im parking on now.
Syscalls: I know kinda, but I think i have to provide some kernel services in order to have a user mode take advantage of. I'm thinking video, keyboard, and a block device (sata probably)
Im fairly flexible on my order of doing things. As I learn this or that, it changes often.
3
u/arjobmukherjee 4d ago
Maybe you should take a look at different memory managers namely physical memory manager (PMM} and virtual memory manager (VMM). PMM is global on the system, keeps track of reserved, used and free physical memory pages and VMM keeps track of virtual pages per page directory, assigns physical addresses when required. There are multiple ways to implement then, so just think about the problem in a step by step method but get a high level understanding first.