Marcelo Tosatti wrote:
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?
Do live migration for windows guest (standard hal), the time on the
destination advances way too slow.
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.
As you said, this can be fixed.
- 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).
While you have a point, there are many IPIs when running smp without NPT
and we can still
do nice performance (thanks for your mmu work..)
That cost is non-existant with timers locked to the vcpu.
Maybe we can keep the pit logic and implementation in userspace like
today, use the kernel timer like today, but when
did timer will pop we'll force the vcpu to go to userspace and run the
pit code in the vcpu context.
We'll pay ctx from passing kernel->user->kernel. Hmm, I think that too
costly.
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?
Eventually I don't really know, I saw newer email from Sheng. If the
interrupt injection path is too slow then we might keep Sheng's pit.
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
