Hey,
I'm trying to make a scalable os, and while going into protected mode, it seems I need to decide beforehand atleast the basic structure of the way things are stored in memory. Right now, what I could come up with is (starting from memory 0x0): GDT, LDT, IDT, Kernel Code related to booting, ISR's, Hardware Routines, etc. I had the following questions:
1. Do we need to load all the ISR's beforehand itself when entering protected mode? Is it ok if I make entries only for most important/common interrupts before hand and change IDT later?
2. I don't know the size of the various modules of code. For eg, I don't know the size of booting related kernel code. Then how should I know where the ISR's should be loaded to? Do I simply pick an arbitrary location and pray my kernel code "fits" before that?
3. I'm trying to build an OS, whose main purpose, is to act as a base for Virtual machine softwares. In that case, is flat memory model the best way to go? Or is it better to carefully segment memory?
4. Consider there is a module of code related to memory management, and one, related to processes. Should the code for memory management use services of the process manager (or vice versa) (as in should the memory manager be considered as a process, or should the memory management of the process manager be handled by the memory management? ). Or should I just make them completely independent?
5. This is more of a coding question: Consider I make ISR's completely in 1 assembly file. Could I get the locations where all the functions will be loaded into, so I can arrange them in the IDT.
Questions on Design of sections
Re: Questions on Design of sections
Hi,
You can construct the IDT dynamically after that - for e.g. create an IDT with one IDT entry for the NMI handler and 255 "not present" entries, then load the IDT (LIDT instruction), then add or change IDT entries whenever it you like. The only real restriction is that an IDT entry needs to exist before it can be used. This means that (for e.g.) you'd need to install an invalid opcode exception handler before you accidentally cause an invalid opcode exception; and if you cause an invalid opcode exception before the invalid opcode exception handler is installed then you'll get a general protection fault (which will become a double fault if the general protection fault handler hasn't been installed; which will become a triple fault/reset if the double fault exception handler hasn't been installed).
A hypervisor is not a normal application. If your OS is a hypervisor, then you'll need to do a lot more research into Intel's virtualization instructions and AMD's virtualization instructions and decide for yourself. I'd assume that the number of "32-bit only" CPUs that support virtualization instructions is too small to bother with, and that you'd want to write a 64-bit hypervisor, and you might have to use long mode to access the full CPU's state (which means you'd have no choice and would need use a flat memory model on top of paging). I haven't done much research though (I've only had a quick look into adding support for virtualization to a general purpose OS that uses a flat memory model on top of paging anyway).
I don't think there's enough information in these questions for anyone to provide useful advice...
Cheers,
Brendan
You don't need any IDT when entering protected mode, although I'd recommend loading a NULL IDTR (with "IDT_limit = 0") to ensure that the CPU will triple fault if an NMI occurs.instance wrote:1. Do we need to load all the ISR's beforehand itself when entering protected mode? Is it ok if I make entries only for most important/common interrupts before hand and change IDT later?
You can construct the IDT dynamically after that - for e.g. create an IDT with one IDT entry for the NMI handler and 255 "not present" entries, then load the IDT (LIDT instruction), then add or change IDT entries whenever it you like. The only real restriction is that an IDT entry needs to exist before it can be used. This means that (for e.g.) you'd need to install an invalid opcode exception handler before you accidentally cause an invalid opcode exception; and if you cause an invalid opcode exception before the invalid opcode exception handler is installed then you'll get a general protection fault (which will become a double fault if the general protection fault handler hasn't been installed; which will become a triple fault/reset if the double fault exception handler hasn't been installed).
An emulator is just an application. If your OS is to act as a base for emulators, then it's mostly a general purpose OS, and I'd strongly recommend a flat memory model on top of paging.instance wrote:3. I'm trying to build an OS, whose main purpose, is to act as a base for Virtual machine softwares. In that case, is flat memory model the best way to go? Or is it better to carefully segment memory?
A hypervisor is not a normal application. If your OS is a hypervisor, then you'll need to do a lot more research into Intel's virtualization instructions and AMD's virtualization instructions and decide for yourself. I'd assume that the number of "32-bit only" CPUs that support virtualization instructions is too small to bother with, and that you'd want to write a 64-bit hypervisor, and you might have to use long mode to access the full CPU's state (which means you'd have no choice and would need use a flat memory model on top of paging). I haven't done much research though (I've only had a quick look into adding support for virtualization to a general purpose OS that uses a flat memory model on top of paging anyway).
If "x = 1", "y = 2" and "z = x + y", then what should "t" equal?instance wrote:4. Consider there is a module of code related to memory management, and one, related to processes. Should the code for memory management use services of the process manager (or vice versa) (as in should the memory manager be considered as a process, or should the memory management of the process manager be handled by the memory management? ). Or should I just make them completely independent?
5. This is more of a coding question: Consider I make ISR's completely in 1 assembly file. Could I get the locations where all the functions will be loaded into, so I can arrange them in the IDT.
I don't think there's enough information in these questions for anyone to provide useful advice...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.