From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [PATCH 2/2] Remove -tdf Date: Fri, 25 Jul 2008 01:55:16 +0300 Message-ID: <48890854.90208@qumranet.com> 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> <48868769.7050307@codemonkey.ws> <20080723055825.GA3196@minantech.com> <48874EBC.1050209@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org, Avi Kivity To: Anthony Liguori Return-path: Received: from il.qumranet.com ([212.179.150.194]:43245 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751287AbYGXW4x (ORCPT ); Thu, 24 Jul 2008 18:56:53 -0400 In-Reply-To: <48874EBC.1050209@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > 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. > We'll add time drift tests to autotest the minute it starts to run enough interesting tests/loads. In our private test platform we use a simple scenario to test it: 1. Use windows guest and play a movie (changes rtc on acpi win/pit on -no-acpi win freq to 1000hz). 2. Pin the guest to a physical cpu + load the same cpu. 3. Measure a minute in real life vs in the guest. Actually the movie seems to be more smooth without time drift fix. When fixing irqs some times the player needs to cope with too rapid changes. Anyway the main focus is time accuracy and not smoother movies. In-kernel pit does relatively good job for Windows guests, the problem its not yet 100% stable and also we can do it in userspace and the rtc needs a solution too. >> 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. >> >