On Mon, Nov 16, 2009 at 11:13 PM, Christoffer Dall <cd2436 at columbia.edu> wrote: > 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! You're probably past this point already, but for reference: On PowerPC, the decrementer (timer interrupt) is an on-core facility. Since the rough breakdown of KVM vs Qemu functionality is core+memory vs IO, PowerPC KVM emulates guest decrementer accesses without Qemu. (This isn't just a theoretical thing; doing it in qemu would require slurping a number of supervisor registers into userspace in order to perform the emulation.) On x86, I believe their timers can be provided by the Local APIC and/or the 8254 PIT. They originally let qemu handle the emulation, but for performance reasons later added in-kernel emulation for these devices. (One implication of this design decision is that save/restore and live migration must extract the state of those devices into user space in order to transfer it to the remote system.) We had much more severe performance problems on PowerPC, so exiting to userspace on timer accesses did not cause significant overhead. ;) -Hollis
