Comment 5 for bug 1243287

(1) If you are trying to mmap /dev/mem then you are going to be accessing physical addresses. This is obviously totally board specific. In particular the memory layout between a Midway system and a KVM virtual machine is likely to be different (you don't say what QEMU configuration you're using) so it is unsurprising that looking at /dev/mem address zero gives different effects between the host and the VM. If dmidecode wants to access physical address space it needs to be aware of the physical memory layout of every board it might run on (and that is an enormous range of systems for ARM).

(2) The guest kernel has sufficient privilege to cause kvm to exit (the easiest way it can do this is to do something that KVM doesn't support, such as trying to access emulated devices via LDM/STM or some other "complex" instruction). If you let your guest userspace open /dev/mem it has equivalent privilege and can do the same thing (again, by trying LDM on device MMIO space)

(3) My kernel sources don't have any references to CONFIG_STRICT_MEM, and the only two google hits are references back to this bug report, so I'm not sure what this is.

My best guess is that there are two underlying bugs here:
a. CONFIG_STRICT_MEM (whatever that is) either doesn't work with ARM or doesn't work with KVM or doesn't work with KVM/ARM
b. dmidecode is making bad assumptions about the physical memory layout of the machine it is running on and needs to be fixed somehow (what does it think is the actual data it is copying out of physical memory??)