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

[Jan Kiszka]

Avi Kivity wrote:
> On 07/05/2010 12:07 PM, Jan Kiszka wrote:
>>
>>> What about ack notifiers?  Ask the APIC to notify you when an interrupt
>>> is acked.  That allows you to track the BSP, all cpus, or some subset.
>>> Masking can be seen at the irq controller level.
>>>      
>> So, if I understand you correctly, an IRQ state change that is ignored
>> due to masking would invoke the ack notifier chain as well?
>>    
> 
> No - the cpu doesn't ack, no ack notifier.
> 
> We might need a separate mask notifier.  Just add pomodoro sauce.

Mask notifiers would be a must, otherwise you cannot tell apart if an
IRQ was not yet ack'ed or is actually masked. On the other hand... see
below.

> 
>>> It's more involved, but provides more information.
>>>      
>> Well, it requires to establish ack notifier chains in parallel to the
>> existing IRQ delivery routes. Definitely more invasive.
>>    
> 
> Right, and need to plumb it twice, once for qemu and once for kvm.
> 
> But my feeling is you get a lot more information out of it.

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. Not really straightforward to handle, is it?

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?

Jan

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