Comment 8 for bug 1243287

Peter, the config option is called: CONFIG_STRICT_DEVMEM
And /dev/mem behaves differently between doing read() and doing mmap().

As Peter already hinted, the memory layout is different on native Midway (which has DRAM starting at 0) and mach-virt/vexpress (which start at 128MB / 2GB respectively). So accessing 0xf0000 reads memory on native, but faults in stage 2 mapping in the host kernel.
But the actual problem is that the host kernel passes this abort on to userspace, where QEMU just does abort(), thus crashing the whole virtual machine. Actually I think we should change the host kernel to inject the data abort into the guest. I tested this with a simple patch, it now makes dmidecode crash (due to a signal), but keeps the guest alive.

This approach needs some discussion on the ML, I guess.

But near term we should not call dmidecode on ARM, since AFAIK it does not give any information. There once was a discussion on patching dmidecode to output hardcoded or elsewhere gathered information to make scripts happy, but I don't know where this ended.