|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. |
Date: | Fri, 31 Oct 2008 14:17:19 -0500 |
User-agent: | Thunderbird 2.0.0.17 (X11/20080925) |
Gleb Natapov wrote:
Qemu device emulation for timers might be inaccurate and causes coalescing of several IRQs into one. It happens when the load on the host is high and the guest did not manage to ack the previous IRQ. The problem can be reproduced by copying of a bigfile or many small ones inside Windows guest. When you do that guest clock start to lag behind the host one.The first patch in the series changes qemu_irq subsystem to return IRQ delivery status information. If device is notified that IRQs where lost it can regenerate them as needed. The following two patches add IRQ regeneration to PIC and RTC devices.
I don't think any of the problems raised when this was initially posted. Further, I don't think that always playing catch-up with interrupts is always the best course of action.
As I've said repeatedly in the past, any sort of time drift fixes needs to have a lot of data posted with it that is repeatable.
How much does this improve things with Windows? How does having a high resolution timer in the host affect the problem to begin with? How do Linux guests behave with this?
Even the Windows PV spec calls out three separate approaches to dealing with missed interrupts and provides an interface for the host to query the guest as to which one should be used. I don't think any solution that uses a single technique is going to be correct.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |