Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups

[Avi Kivity]

On 07/05/2010 02:13 PM, Jan Kiszka wrote:
> That decoupling between state change and acknowledgment worries me.
> Dispatching a source to multiple sinks or sharing a sink between
> multiple source is no longer cleanly manageable this way. Just look at
> the route of some ISA IRQ on x86: You may get an 'ack' from IOAPIC side
> and a 'masked' from the ISA side (or vice versa). And the 'masked' will
> arrive earlier.

I think it is sufficient to only note masks and take action on acks.

> Not really straightforward to handle, is it?
>    

No question.

> Moreover, it requires a concrete algorithm that takes advantage from the
> 'ack' information bit (that should be the only additional information
> you gain) to justify the additional effort. A "might have some
> advantages" is not enough IMO. Do we have such an algorithm already?
>    

No.

The additional information is that you know which cpu(s) processed the 
interrupt, and when exactly.  I don't know how to translate it to a 
functional advantage, I just have a feeling that it is possible.

It's also architecturally cleaner.  Masks and acks are architectural 
events.  Injections are not - there's the edge on the LINT0 or INTI2 
pins, generation of an APIC message, receipt of the APIC message, and 
assertion of the APIC-to-core interrupt interface.  I'm not sure how the 
proposed interface maps to that.

--
error compiling committee.c: too many arguments to function