Christoffer Dall wrote: > 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. phew .. nice progress ! as per your dilemma (disclaimer: I'm no expert on ARM, KVM or QEMU): my guess as that acting purely on timers is insufficient. instead, you need to learn how the PL011 operates. if each IO (read/write) to the buffer creates interaction with the physical device, then you will need to trap on each access. if, on the other hand, only specific accesses create interaction (e.g. kernel first fills a buffer with characters, then trigger an action using a control register of the device), then you can simply trap the latter. (hopefully they reside in a separate page...) Oren.
