Hi Dor, On Wed, Jul 30, 2008 at 12:50:06AM +0300, Dor Laor wrote: > Marcelo Tosatti wrote: >> The in-kernel PIT emulation can either inject too many or too few >> interrupts. >> >> > While it's an improvement, the in-kernel pit is still not perfect. For > example, on pit frequency changes the > pending count should be recalculated and matched to the new frequency.
Point. That one can be addressed. > I also tumbled on live migration problem Can you provide more details? How to reproduce? > and there is your guest smp fix. > IMHO we need to switch back to userspace pit. [Actually I did consider > in-kernel pit myself in the past.]. The reasons: > 1. There is no performance advantage doing this in the kernel. > It's just potentially reduced the host stability and reduces code Keeping device emulation in userspace is desired, of course. The drawbacks of timer emulation, AFAICS, are: - Timers in QEMU are, currently, not handled separately from other IO processing. The delay between timer expiration and interrupt injection depends on the time spent handling unrelated IO in QEMU's main loop. This can be fixed, by treating guest timer expiration with higher priority. - The in-kernel emulation allows the host timer to be locked to the vcpu it belongs. With userspace emulation, an IPI is necessary whenever the iothread is running on a different physical CPU than the target vcpu. The overall cost to wakeup a vcpu in a different physical CPU is: syscall, IRQ lock acquision (currently kvm->lock, which also protects access to in-kernel devices) and finally the IPI cost, which is hundreds of ns (googling around it seems to be in the range of 700ns). That cost is non-existant with timers locked to the vcpu. I don't know what specific problems the in-kernel PIT emulation solved (I recall certain Windows configurations were largely improved). Do you the details? Sheng? > 2. There are floating patches to fix pit/rtc injection in the same way > the acked irq is sone here. > So the first 2 patches are relevant. > 3. Will we do the same for rtc? -> why duplicate userspace code in the > kernel? > We won't have smp issues since we have qemu_mutex and it will be > simpler too. > > If you agree, please help merging the qemu patches. > Otherwise argue against the above :) > > Cheers, Dor > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
