From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51941 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVkbi-0001Mk-N2 for qemu-devel@nongnu.org; Mon, 05 Jul 2010 08:17:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVkbh-0006fL-Hr for qemu-devel@nongnu.org; Mon, 05 Jul 2010 08:17:06 -0400 Received: from thoth.sbs.de ([192.35.17.2]:15399) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVkbh-0006eb-9W for qemu-devel@nongnu.org; Mon, 05 Jul 2010 08:17:05 -0400 Message-ID: <4C31CD38.5050904@siemens.com> Date: Mon, 05 Jul 2010 14:16:56 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups References: <20100629211802.16137.10587.malonedeb@soybean.canonical.com> <4C2EECE8.8030305@web.de> <201007042306.57852.paul@codesourcery.com> <4C317E2A.7090101@web.de> <20100705064239.GI4689@redhat.com> <4C31807B.2030401@web.de> <20100705070017.GJ4689@redhat.com> <4C318B74.3040403@web.de> <4C319C30.30308@redhat.com> <4C31A0EC.7020803@web.de> <4C31A477.7010205@redhat.com> <4C31BE6A.70307@siemens.com> <4C31C4A3.4070208@redhat.com> In-Reply-To: <4C31C4A3.4070208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , Paul Brook , Gleb Natapov , "qemu-devel@nongnu.org" 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