This weeks status: Last week we were dealing with a memory mis-alignment fault. The fault turned out to be caused by a bug in the data abort handler. When a data abort handler occurs the PC is at the faulting instruction + 8 bytes, wheres it is at the faulting instruction + 4 bytes on a prefetch abort. Thus, if there's a missing shadow page table entry, we can add it, and reset the PC to the faulting instruction and switch to the guest for re-execution of the instruction. In my code, I subtracted 4 bytes in either cases so data was never loaded. Now, the guest boots until it wants to print the "Decompressing kernel....." message. It faulted on the putc() function in arch/arm/boot/compressed/misc.c, while writing to the default PL011 (serial device) physical memory region beginning at address 0x16000000. Initially KVM didn't know anything of this memory area, since the memory was never really allocated by QEMU as it is only used for MMIO and thus QEMU never told KVM about that memory region. I changed the hw/pl011.c emulation code for PL011 in QEMU to actually reserve the memory and mark it as IO_MEM_RAM from QEMU's point of view, but I am getting errors with the host running out of memory. This seems weird to me, as user space allocation should simply reserve address space and not physical memory, but I will investigate further. It is clear though, that me (and Michael) must now get a good understanding of how the MMIO works with QEMU and especially in conjunction with KVM. What happens when the guest writes a character to the PL011 buffer? Or tries to read a status register? Should the memory be protected, trap to KVM, which switches to QEMU and back and emulates the result, or can the writes to the memory happen directly and QEMU acts on them only during timers? I think these questions should be answered before much additional coding can be done. Best, Christoffer
