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 ..
interrupt handling with paging
- gzaloprgm
- Member
- Posts: 141
- Joined: Sun Sep 23, 2007 4:53 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: interrupt handling with paging
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
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.
Re: interrupt handling with paging
Hi,
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
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.osmosys wrote:We give kernel's code segment in IDT, but what about the kernel's page table ?
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
Re: interrupt handling with paging
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?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.
Re: interrupt handling with paging
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.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
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
Re: interrupt handling with paging
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?
Re: interrupt handling with paging
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.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?
JAL