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.
--
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
