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

[Jan Kiszka]

Gleb Natapov wrote:
> On Mon, Jul 05, 2010 at 02:16:56PM +0200, Jan Kiszka wrote:
>> 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.
>>
> On mask notification backlog is zeroed and not incremented until unmask
> notification.

OK, so your idea is that mask/unmask notifiers report masking state
changes. I somehow had a different model in mind. Mmm, may work if we
put additional logic into those IRQ routers that have more than one
output per input. Only if all possible outputs are masked, this event
would be propagated up.

But how to deal with multiple acks per input due to multiple open
outputs (not just to different CPUs)? We either need to enable the
router to filter redundant information or support the injection source
with processing all acks properly.

And is there some scenario where the time-keeping device is sharing its
IRQ line with some other device? De-coalescing workarounds would not
work then if they were notifier based.

Jan

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