OSDev.org

I am trying to stash all non- main memory address ranges (meaning everything that is not CONVENTIONAL/LOADER_XXX) into the low part of the pagetree and then everything else into the top of memory.
The problem is that i have no idea how i would survive the setting of the pagetree unless the code i am running is identity mapped, before trying to implement this i was putting code, pagetree and data structures into a gigabyte, identity mapped, global page but what if the main memory has been mapped by hardware lower than the mmio ranges or vram or whatever?

So basically it is impossible D:

This is probably unusual but can you guys tell me whether your hardware always maps main memory address ranges at the top of the address space? Mine does but idk...

Linux: sudo dmesg -H
Windows: no idea

hatto wrote: ↑Thu Aug 22, 2024 5:56 am The problem is that i have no idea how i would survive the setting of the pagetree unless the code i am running is identity mapped,

Yes, that is exactly how you enable paging. However, nothing requires you to stay identity mapped afterwards.

I've always preferred having two independent executables for paging. One that runs without paging, and the main kernel then runs with paging enabled. The loader (as I'll call the first binary) sets up the paging according to the structures in the kernel binary. You can compile the kernel to a normal ELF and just map it like it was a static exe. And how do you hand over parameters? Why not put them on the initial stack, just like is done for normal executables?

The loader must necessarily identity map itself, but after jumping to the main kernel, it can then clean up that temporary map and proceed to not think about it.

For dealing with physical memory, I would simply map all of RAM to the start of kernel space, and not bother with anything else until a driver requests it. The driver can then say what memtype it wants (e.g. uncacheable for MMIO, or write-combining for frame-buffers).

I think I had brainfarted and not realized that since two virtual pages can refer to the same physical page copying that gigabyte in the pagetree high up, then doing all of the mapping and then switching back and making the gigabyte page global is viable.

For dealing with physical memory, I would simply map all of RAM to the start of kernel space,

that seems like a bad idea though, if you need to access a userspace process' memory in a system call you are going to need to use a really expensive function such as phys_to_vm() on the kernel pagetree for that mapping to not be useless (after having extracted the physical page from the process' tree).
I am thinking of just mapping on the fly whatever i need at runtime

not bother with anything else until a driver requests it. The driver can then say what memtype it wants (e.g. uncacheable for MMIO, or write-combining for frame-buffers).

I should do that

From the 2.10:
" If an operating system chooses to make EFI runtime service calls in a virtual addressing mode
instead of the flat physical mode, then the operating system must use the services in this section to switch the EFI
runtime services from flat physical addressing to virtual addressing."

I am guessing firmware doesnt switch to a reserved pagetree so we do have to map the stuff

Strange thread lole,

hatto wrote: ↑Thu Aug 22, 2024 10:44 am that seems like a bad idea though, if you need to access a userspace process' memory in a system call you are going to need to use a really expensive function such as phys_to_vm() on the kernel pagetree for that mapping to not be useless (after having extracted the physical page from the process' tree).

Why would you need to do that? I was talking about doing that in addition to everything else. Because sometimes you do need to access memory by physical address, and having a linear mapping like that makes that really simple. But of course userspace memory is still available under its userspace address.

hatto wrote: ↑Thu Aug 22, 2024 11:07 am I am guessing firmware doesnt switch to a reserved pagetree so we do have to map the stuff

Whatever for? For the most part, just load whatever you need of your kernel into memory, then exit boot services and forget about UEFI entirely. You set up GOP once, and then you have your framebuffer. And you go into paged mode only after that.

hatto wrote: ↑Thu Aug 22, 2024 11:07 am Strange thread lole,

Weirdest of all, you reported yourself for extremely low quality, and I don't understand it. I closed the report all the same.

But of course userspace memory is still available under its userspace address.

If you are doing a fixed mapping for the kernel like linux with the top-half thing, i am switching to the one ring0 pagetree on every context switch so that arenas may grow big

Whatever for? For the most part, just load whatever you need of your kernel into memory, then exit boot services and forget about UEFI entirely.

yeah but when i do need to make a call such as set_rtc() am i not going to have to map that stuff though?
Because of the way i do drivers i am not going to reuse memory redundantly so i might as well just get it done at boot no?

hatto wrote: ↑Thu Aug 22, 2024 2:07 pm yeah but when i do need to make a call such as set_rtc() am i not going to have to map that stuff though?

Or you just implement an RTC driver for the platform you are on. A lot easier than conforming to UEFI's limitations.