From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 2/2] Remove -tdf Date: Tue, 22 Jul 2008 20:20:41 -0500 Message-ID: <48868769.7050307@codemonkey.ws> References: <1216756217-21888-1-git-send-email-aliguori@us.ibm.com> <1216756217-21888-2-git-send-email-aliguori@us.ibm.com> <48865934.8070007@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity , Gleb Natapov To: Dor Laor Return-path: Received: from wr-out-0506.google.com ([64.233.184.238]:47569 "EHLO wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718AbYGWBVO (ORCPT ); Tue, 22 Jul 2008 21:21:14 -0400 Received: by wr-out-0506.google.com with SMTP id 69so1148020wri.5 for ; Tue, 22 Jul 2008 18:21:12 -0700 (PDT) In-Reply-To: <48865934.8070007@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: Dor Laor wrote: > Anthony Liguori wrote: >> The last time I posted the KVM patch series to qemu-devel, the -tdf >> patch met with >> some opposition. Since today we implement timer catch-up in the >> in-kernel PIT and >> the in-kernel PIT is used by default, it doesn't seem all that >> valuable to have >> timer catch-up in userspace too. >> >> Removing it will reduce our divergence from QEMU. >> >> > IMHO the in kernel PIT should go away, there is no reason to keep it > except that userspace PIT drifts. I agree fully :-) But there's certainly no reason to keep -tdf and the in-kernel PIT. Since we're using the in-kernel PIT right now, I'd like to get rid of -tdf. > 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. I'd still like to see some harder evidence of the benefits of tdf. For a specific guest, with a specific configuration, how much better is the drift with this series. The answer shouldn't be "movie's play better" :-) 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. Regards, Anthony Liguori