Korona wrote:
It's possible that your computers have a memory hole at or around 16 MiB. That can be the case even if they have large amounts (i.e. GiB range) of memory installed. ISA devices for example could not perform DMA to >= 16 MiB addresses and are sometimes mapped just below 16 MiB. The only way to be sure that there is physical memory at that (or any other) location is to check the BIOS.
I think the Memory Hole would perfectly explain this and was something that I failed to take into account, "
and given that we are booted by GRUB it looks difficult to find the holes" - Scrap that, read into the multiboot structs more carefully and facepalmed as I realized it is all in there. Thank you so much for your help, I will let you know if this solves the issue - if it does, I owe you a beer.
LtG wrote:
Quote:
If I try this on VirtualBox (i386) with Hardware or Paravirtualization enabled, it doesn't write or read the value, but again, no GPF or Page Fault occur.
How do you know it doesn't write it? What happens instead?
As for what Korona mentioned, you basically have two choices if using BIOS (as opposed to UEFI which is different):
- Use GRUB or something
- BIOS E820 (
http://wiki.osdev.org/Detecting_Memory_(x86)#BIOS_Function:_INT_0x15.2C_EAX_.3D_0xE820)
By the looks of it, Qemu is saying that all four 4MiB virtual pages map to 0x0 physical?
In your memory dump "0x000030e3":
If I deciphered that correctly it would seem that that page is dirty, so you have written to it, which would be same thing "info tlb" is saying. You should probably also check what is actually loaded in CR3.. Qemu "info registers" might show it..
We write to the memory and then attempt to read back, the Dirty Flag and Accessed flag are both being set, but the data read back is all 0's.
We are being booted by GRUB.
As for the QEmu output: That's what we thought, but upon inspection that doesn't seem the case.