Ethin wrote:
My kernel maps the memory range F59C0h-F59E4h (size 36).
You can only map whole pages. Does this mean you've mapped one page that covers everything from 0xF5000 to 0xF5FFF?
Ethin wrote:
(I've tried to round it up so that it maps the next power of two, but it throws a #gp. If I have it map 4096 pages all the time, the same thing happens; my kernel claims error code 7FFFFFh (according to the AMD manuals, this is a selector index).)
That doesn't make sense as a #GP error code, because it claims the fault is due to an external interrupt using an IDT index higher than 255.
Ethin wrote:
So, what could be causing this? Why is the system claiming a #pf when F59CFh is within the range F59C0h-F59E4h?
If you're testing your OS on real hardware or using hardware virtualization, page fault reporting may be delayed when there's a valid entry in the TLB that hasn't been flushed yet. If it immediately reports the fault when you turn off hardware virtualization, that's why.
It could also be IRQ6 if you haven't set up interrupts properly.
Ethin wrote:
And is there a better way of handling #gps (other than just reporting it)?
If your kernel is not intentionally causing #GP, there is nothing you can do besides report it and halt. (I can't think of any reason to intentionally cause #GP off the top of my head, but swapping memory to disk is an example of intentionally causing #PF.)