Re: [patch 0/3] fix PIT injection

[Dor Laor <dor.laor@qumranet.com>]

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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>