interrupt handling with paging

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
osmosys
Posts: 14
Joined: Sun Oct 05, 2008 4:33 am

interrupt handling with paging

Post by osmosys »

Hi,
What would happen when we have enabled paging and we are running a process at user level and then an interrupt comes. We give kernel's code segment in IDT, but what about the kernel's page table ? We load a different page table for the user process and when the interrupt occurs we have to change to kernel's page table ? Otherwise the interrupt code cannot be found because it is a different page table ..
User avatar
gzaloprgm
Member
Member
Posts: 141
Joined: Sun Sep 23, 2007 4:53 pm
Location: Buenos Aires, Argentina
Contact:

Re: interrupt handling with paging

Post by gzaloprgm »

Well, most kernels will map themselves in each application to somewhere in memory, so the processor can access GDT,IDT,TSS,Page Directory, etc.

If you don't want to map the whole kernel section you can only include needeed elements (AFAIK GDT,IDT,TSS)

Cheers,
Gonzalo
Visit https://gzalo.com : my web site with electronic circuits, articles, schematics, pcb, calculators, and other things related to electronics.
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Re: interrupt handling with paging

Post by AJ »

Hi,
osmosys wrote:We give kernel's code segment in IDT, but what about the kernel's page table ?
As gzaloprgm correctly says, the normal way to do this is to map the kernel address space in to a part (often the top) of each address space. At least the code that runs following the interrupt needs mapping in this way, and so does the ring 0 stack and any data used.

Once you have got to this point (ISR Running, ESP running in ring 0, data all loadable), you are in the kernel and can do what you like. Therefore, if there is a good reason for having the rest of the kernel paged out, you can reload CR3 at this point. It does sound like this would complicate things, so have a good reason for doing this (such reasons could be that you are writing an exo- or nanokernel).

Cheers,
Adam
User avatar
yemista
Member
Member
Posts: 299
Joined: Fri Dec 26, 2008 12:31 pm
Location: Boston
Contact:

Re: interrupt handling with paging

Post by yemista »

As gzaloprgm correctly says, the normal way to do this is to map the kernel address space in to a part (often the top) of each address space. At least the code that runs following the interrupt needs mapping in this way, and so does the ring 0 stack and any data used.
What do you mean by this? If I understand this correctly, if you have a 1:1 mapping for your kernel within the pages, and setup paging, shouldnt interrupts work no matter what? I thought idtr and gdtr contain absolute addresses, so once these registers are loaded they know where to look, so if an interrupt occurs, everything should play out the same whether you are using paging or not?
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: interrupt handling with paging

Post by jal »

yemista wrote:What do you mean by this? If I understand this correctly, if you have a 1:1 mapping for your kernel within the pages
The IDTR holds the linear address of the interrupt table. This means that when an interrupt occurs, the address pointed to by the IDTR must be in a page that's mapped and available in the context of the current running task. If it's not, you'll get a tripple fault and die. Next, assuming the IDT is mapped correctly, the CPU reads the linear address of the interrupt procedure from the IDT. This address must also be in a page that's mapped and available. If not, you'll get a page fault (which may in turn trigger a tripple fault of the PF handler address is not mapped in). Only when the address pointed to by the IDT entry is available you have a piece of code running in ring 0 (but still using the current page tables), which could change CR3.

Practically this means that both the IDT and the interrupt routines (or at least the PF handler) must be mapped by the running task's page tables.


JAL
User avatar
yemista
Member
Member
Posts: 299
Joined: Fri Dec 26, 2008 12:31 pm
Location: Boston
Contact:

Re: interrupt handling with paging

Post by yemista »

Ok but what do you mean that each process has its own pages mapped and must have kernel pages mapped into it? I think you mean that if you are using a 4GB address space you might have to switch page directories which will change the CR3 register, but if you are not doing that, and you only use one directory and have kernel code mapped into it and also have use code mapped into it, should interrupts work smoothly without having to touch the memory manager?
jal
Member
Member
Posts: 1385
Joined: Wed Oct 31, 2007 9:09 am

Re: interrupt handling with paging

Post by jal »

yemista wrote:Ok but what do you mean that each process has its own pages mapped and must have kernel pages mapped into it? I think you mean that if you are using a 4GB address space you might have to switch page directories which will change the CR3 register, but if you are not doing that, and you only use one directory and have kernel code mapped into it and also have use code mapped into it, should interrupts work smoothly without having to touch the memory manager?
If you do not swap CR3 when switching to a task/thread part of a different process then all processes use the same page directory. This means there is no memory protection and each process can trash all others.


JAL
Post Reply