Skip to content
This repository has been archived by the owner on Nov 21, 2017. It is now read-only.

Memory map #33

Open
IanSeyler opened this issue Mar 26, 2013 · 6 comments
Open

Memory map #33

IanSeyler opened this issue Mar 26, 2013 · 6 comments

Comments

@IanSeyler
Copy link
Member

Use the PML4 to keep track of pages in use instead of a separate area of memory?

@Roxxik
Copy link
Contributor

Roxxik commented Jul 7, 2015

Some assumptions from my side:

each 2MiB Page has one Byte in the os_MemoryMap structure
0x01 is free
0x02 is used

the whole memory is identity mapped (behave like paging is off)

PML4 is a structure to keep track of virtual memory pages

From Pure64/Pure64.asm/line 183
; The higher half is identity mapped to the lower half
This comment doesn't make sense to me because identity mapping means mapping to the same address

I'd recommend to set up the paging tables so that we can enter long mode(basically identity map everything) and keep the usage information in a seperate region

This has the drawbacks, that we can't load more than one application at a time unless

  1. we build a loader
  2. we use position independent executables which can be load everywhere

with paging enabled we could load more than one application to virtual address 0x200000, but this hinders IPC because u cannot just share some pointer between the two and but a spinlock infront of it
for that we either have to build some shared memory or build something into the Kernel that can share information between processes

@benaryorg
Copy link
Contributor

The question is if there are plans to make BareMetal-OS a multi-threading and multi-tasking OS.

If yes, then there is another question.
Will it have memory isolation and the usual “a single process cannot crash the whole OS” mechanisms?

Just keep in mind that BareMetal is an exokernel, which means every program will have to supply it's own drivers, which could influence each other.

@benaryorg
Copy link
Contributor

Also a link to what PML4 exactly is: https://lwn.net/Articles/106177/

@IanSeyler
Copy link
Member Author

The idea here is to use the PML4 as the memory map instead of the separate 128KB os_MemoryMap.

I was going to test using the User/supervisor, Accessed, or Dirty bit in each PD entry to mark if a page is actually in use.

More info on those bits are in the Intel SDM docs. Section 4.4.2 - Table 4-9.

@IanSeyler
Copy link
Member Author

Following up the questions from @benaryorg

The BareMetal exokernel supports multi-threading but not in the conventional sense that most operating systems use. A thread is locked to a CPU core in BareMetal. If you spawn 5 "threads" and only have 4 cores then the last thread will only run once one of the first have completed.

No worries on drivers. BareMetal publishes a simple API for the drivers (network and disk).

Right now a single bad program can crash the OS (for instance if you overwrite the IDT at memory address 0x0). There needs to be some work done to make sure that isn't possible.

@ankitCoreProgrammer
Copy link

Will this be Ok if we allocate the pages based on Present flag at the place of os_MemoryMap??
Here it will be required to pre-allocate the pages of IDT and page-fault handler code.
And afterwords we can allocate pages on page-fault.
For initial implementations this to implement, we can try the already loaded pages as not present by marking the page-flags in pagetables(PDE's) to not present(demand paging)[i have already tried the page-fault handler working fine for Pure64, and exact pages need to identity which should be kept pre-allocated for BareMetalOS(like for new IDT, SMP..)].
Can work on loading pages from disk later on(which ideally required.) by taking the file-sector number and offset-sector into it to be linked to particular PDE entry.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants