|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups |
Date: | Mon, 05 Jul 2010 14:40:19 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |