Hi there. We now get pretty far into the kernel generic initialization code. Specifically the guest runs start_kernel until it calls calibrate_delay(), where it ends up in an infinite loop. The infinite loop is caused by the guest not receiving timer interrupts. Timer interrupts ---------------------- I am thinking that we can either implement timer handling directly in KVM or use whatever QEMU uses and place a KVM hook in there. The latter might be somewhat easier, but clearly introduces a larger lack between host and guest timer interrupts as we have to switch back to user space on each signal. To implement a timer directly in the kernel, I guess we can check every IRQ and see if was caused by a timer and inject an IRQ to the guest then, but we would still have to find a way to inject interrupts into the guest even when another process is executing on the host. If anyone on the list can give their views on how they think to proceed, it will be greatly appreciated! Past weeks activities ---------------------------- When the guest sets up interrupt vectors it tries to write to 0xffff0000. This page is, however, used by the host for the actual hardware interrupt handlers and thus we cannot let the guest read/write that virtual address. We went over some ways of handling this, including paravirtualization, relocation of guest handlers and switching host handlers to low interrupt vector location (0x00000000). We generally want to paravirtualize as little as possible (if at all) so that approach was dropped. Relocation is slow and requires the guest handler to be position independent, which cannot be guaranteed. Finally, we decided to move the host handlers (only when executing a guest, not under normal host kernel operation). The only issue here would be guest NULL pointer checks and guest user code executing in page 0. NULL pointer checks is not a problem since the page is neither readable nor writable by the guest and any access would still trap to the guest kernel. However, if the guest maps in user space code in page 0, we have to switch back to high interrupt vector locations for the host handlers and map in the corresponding guest page on address 0 in the shadow page table until we get an interrupt that needs to be handled by the guest, switch back, and so forth. However, since all interrupts go through the host kernel anyway, the overhead in such a scenario shouldn't be much larger than if no switches of vector location was required. The guest has also started to use small page and coarse L1 page tables and support for traversing these have been implemented. We are still not checking if the guest has access for the virtual cpu mode on each translation, but it will follow. Whenever we experience a translation fault on the guest page tales (not shadow page tables) we successfully inject interrupts to the guest which works as expected. Thanks, Christoffer
