Location of interrupt routines in multitask/paged x86

[samiam95124]

Hi,

First of all, thanks so much for the osdev community and resources, I find it very helpful.

I am new to kernels in x86, and looking at software context switching vs. hardware. Obviously software switching is acknowledged as better, by many parties including OSdev. However, this has implications for tasking in a page managed system, specifically handling interrupts. This article has a good overview on this:

https://stackoverflow.com/questions/325 ... 6-machines

To wit:

"An implication of this is that the code for the interrupt handler must be accessible in every virtual address space in which an interrupt may occur. Because of that, and because such a handler usually calls additional code from the kernel, most kernels map a good portion of their own code and data into the address space of every process, reducing the available memory space for each process. Usually this mapping is established at the "upper end" of the addressable memory space, around 3GB."

First, might I say, this is UGLY. At 64 bit mode, it gets worse, since there is no hardware context support at all. Reading through the AMD 64 bit (long mode) docs, there does not seem to be any help for this. AMD says:

"exception and interrupt handlers should be made reachable from software running at any privilege level that requires them". This tends to imply that 64 bit mode entrenches this very strange requirement that interrupt handlers are forced to be mapped into user space.

Ok, here's the question:

How can this work in a virtual partition? Virtuals are supposed to be clean. It gets a bit hard to explain why there is a strange hole in the memory space of a virtual machine.

Or is there yet another fix for this in a virtual machine extension like VT-x?

Thanks in advance.

Scott Franco
San Jose

[iansjack]

First, might I say, this is UGLY. At 64 bit mode, it gets worse, since there is no hardware context support at all.

That is completely wrong. In 64-bit mode the problem disappears as you have (effectively) as many free logical addresses as you could possibly want.

[bzt]

Saying around 3GB assumes that they were talking about 32 bit protected mode. Please don't forget that this is not the only way to do things. For example I use 64 bit and I map my kernel at the "upper end" as well, yet I only "waste" 2Mb of each process' address space. It's important to point out that by mapping kernel to every address space does not waste RAM, only address space, which does not matter (even reducing the 256T address space by 1G seems insignificant, not to mention 2M). And many on this forum can tell you that 2M is quite a lot of memory to fill up with code. For interrupt handlers and software task switch code 1/10th would be more than enough. The reason why I've chosen 2M is because it's the size of a page directory (512*4096) meaning I can map the entire kernel space with setting a single 64 bit pointer.
And about the "strange hole": think about it as a signed value, and it will make sense at once. Memory is addressed from -128T to 128T on x86_64.