Re: [Qemu-devel] Re: [PATCH 1/3] Change qemu_set_irq() to return status information.

[Dor Laor]

On Sun, 2008-06-29 at 22:16 +0100, Paul Brook wrote:
> On Sunday 29 June 2008, Jan Kiszka wrote:
> > Paul Brook wrote:
> > >> The model takes into account that not all interrupt controller are
> > >> capable to detect missed interrupt (it is possible that there is no
> > >> interrupt controller at all). In this case irq function should
> > >> return one and everything will fall back to how it works now.
> > >
> > > On a related note the correct way to fix this is "-icount auto".
> > > You should make sure that your hacks are not enabled when we have a
> > > realistic virtual timebase.
> >
> > Virtual timebases don't help if the guest has to interact with the real
> > life - ie. clocks you cannot tweak. In the end, you will have to bring 
> > them in sync again, so this approach basically points in the right
> > direction.
> 
> That's exactly what -icount auto does. It gradually varies the virtual clock 
> rate to keep it in line with the outside world. You get some clock skew, but 
> that true whatever you do (including the proposed patch).
> 

Do you mean it slows down the virtual clock?
It's good for emulation and correctness, but not for production VMs.

> In my experience hacks to prevent "coalescing" of interrupts cause as many 
> problems as they solve. The guest OS can get awfully confused when it 
> compares two different time sources and gets wildly different and conflicting 
> answers. I believe VMware has some fairly sophisticated hacks for this, but 
> it often still doesn't work in practice.
> 
> Paul
> 


The current approach works well for windows guests, whether they use rtc
(acpi HAL) or pit (standard HAL). It even works if dozens of coalesced
irqs are injected one after another.

The problem you're describing about two different time source can still
happen without time drift fix since there is no global synchronization
of all the time sources (including tsc [Xen do some of it]). Indeed in
theory such two time sources synchronization will jitter with this
patch, but practically it works for Windows. Linux will have its own
para virtual time and even without it offer greater control over the
time source.

The time drift problem is indeed something we need to deal since if you
use a RHEL host, it does not have a user space high precision time, so
qemu timer pops with up to 30-100msec delay. When multimedia is played
in windows guest the timer freq is 1000HZ. This is a potential loss of
100 irqs.

Regards,
Dor