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

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
> 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.

We would increment our backlog on injection, decrement it on mask
notification - and decrement it again on ack.

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

Our emulation does not reflect every architectural detail of the
delivery path anyway. The abstraction is always an IRQ line which can be
high or low (sometimes it is only high, but this is a bug).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux