From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35178 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVlfS-0004kt-Kj for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:25:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVlfQ-0000kR-DP for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:25:02 -0400 Received: from goliath.siemens.de ([192.35.17.28]:20713) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVlfQ-0000k4-35 for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:25:00 -0400 Message-ID: <4C31DD24.6080500@siemens.com> Date: Mon, 05 Jul 2010 15:24:52 +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: <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> <4C31CD38.5050904@siemens.com> <20100705122025.GQ4689@redhat.com> In-Reply-To: <20100705122025.GQ4689@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: Gleb Natapov Cc: Blue Swirl , "qemu-devel@nongnu.org" , Avi Kivity , Paul Brook 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