Re: [PATCH 2/2] Remove -tdf

[Anthony Liguori <anthony@codemonkey.ws>]

Gleb Natapov wrote:
> On Tue, Jul 22, 2008 at 08:20:41PM -0500, Anthony Liguori wrote:
>   
>>> Currently both in-kernel PIT and even the in kernel irqchips are not  
>>> 100% bullet proof.
>>> Of course this code is a hack, Gleb Natapov has send better fix for  
>>> PIT/RTC to qemu list.
>>> Can you look into them:
>>> http://www.mail-archive.com/kvm@vger.kernel.org/msg01181.html
>>>       
>> Paul Brook's initial feedback is still valid.  It causes quite a lot of  
>> churn and may not jive well with a virtual time base.  An advantage to  
>> the current -tdf patch is that it's more contained.  I don't think  
>> either approach is going to get past Paul in it's current form.
>>     
> Yes, my patch causes a lot of churn because it changes widely used API.
>   

Indeed.

> But the time drift fix itself is contained to PIT/RTC code only. The
> last patch series I've sent disables time drift fix if virtual time base
> is enabled as Paul requested. There was no further feedback from him.
>   

I think there's a healthy amount of scepticism  about whether tdf really 
is worth it.  This is why I suggested that we need to better quantify 
exactly how much this patch set helps things.  For instance, a time 
drift test for kvm-autotest would be perfect.

tdf is ugly and deviates from how hardware works.  A compelling case is 
needed to justify it.

> As Jan Kiszka wrote in one of his mails may be Paul's virtual time base
> can be adopted to work with KVM too. BTW how virtual time base handles
> SMP guest?
>   

I really don't know.  I haven't looked to deeply at the virtual time 
base.  Keep in mind though, that QEMU SMP is not true SMP.  All VCPUs 
run in lock-step.

Regards,

Anthony Liguori

>> Also, it's important that this is reproducible in upstream QEMU and not  
>> just in KVM.  If we can make a compelling case for the importance of  
>> this, we can possibly work out a compromise.
>>
>>     
> I developed and tested my patch with upstream QEMU.
>
> --
> 			Gleb.
>