OSDev.org

Here is an interesting problem I'm having. I'm trying to create a kernel. I set up a GDT. At first I set the limit to the maximum 4 gigabytes, with a granularity of 4kb of course. I wanted to test the x86's protection mechanism, so I reduced the limit of my segment to 5120. Multiply that by 4kb and that is 20971520, or 20 MB. Now when I try to access bytes outside of the limit, Qemu doesn't generate a general protection exception. I wracked my brain for hours trying to see if I set up the GDT wrong or what have you. Interestingly, if I try my kernel on my actual machine, the general protection exception does happen. So for some reason, qemu isn't firing an exception when I try to access memory above the 20MB mark I set as a limit...I'm very pleased with Qemu but this sort of disappoints me. Anyone else have a similar experience? Thanks!

Hi,

I have not used qemu, but have certainly had this experience with emulators such as Bochs and MS VPC2004.

The problem was that my code was not setting up paging correctly. The early stages of my kernel were almost exclusively tested on Bochs and when I went over to VPC2004, started getting triple faults - which was extremely disappointing!

I have also had issues where I have not initialised variables correctly - Bochs seemed to zero the memory at initialisation, whereas in VPC I was just getting garbled data (as you should expect). Of course, Bochs was hiding my error because it had pre-zeroed the RAM!

I have now learned the lesson - test on several emulators and real hardware wherever possible. You cannot rely on a single emulator and then assume that your kernel 'works'

If you feel that this is a reproducible error and that your own code is correct, you may like to submit a bug report to the emulator developpers so they can fix it for others in the future.

Cheers,
Adam

Thing #1 to check: have you flushed the descriptor caches?

Once you load a segment register, the corresponding GDT entry is stored in the processor's descriptor caches, saving it from re-reading the GDT over and over. If you modify the GDT or change operating modes, the original values remain intact until you reload the appropriate segment selectors.

Unfortunately yes I have checked that the correct GDT values are being used. I looked at the hidden part of the CS register while Qemu was running and it did indeed contain the correct segment selector. Everything is set up as it should be, and I am intentionally trying to CAUSE a general protection fault, but am not getting one! It must be a flaw in Qemu, unless of course there is something I missed, but I've gone over it over and over and I cannot seem to find a mistake. Plus the fact that the protection fault occurs in real hardware as it should, makes it possible that it's a bug with Qemu. I'm using the latest version. Maybe I should post a bug like suggested. Thanks for the insight, guys!

What's about the A20 gate ? Is it enabled ?

[edit]I don't think it's an emulator problem ... When I started OS development I had lots of problems, and I often thougt that they were because of emulator problems, but allways I found out that it was a simple mistake, made by me. The only emulator problems I had are, that it WORKS on emulator, but not a real machine.[/edit]

Otter thanks again for replying, you replied in another post of mine. I assume the A20 gate is enabled simply because I'm using Grub as a bootloader and it is known for having fairly good code for switching to Pmode, including caveats of certain systems. I assume it's an emulator problem because it works in actual hardware, and not in the emulator. Someone told me that Qemu bypasses certain checks to run faster. Skipping checking of the limit of a segment each time memory is accessed sounds like a good way to boost performance!