From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54070 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVpk9-0002zK-4M for qemu-devel@nongnu.org; Mon, 05 Jul 2010 13:46:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVpk7-0007IG-Vr for qemu-devel@nongnu.org; Mon, 05 Jul 2010 13:46:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61284) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVpk7-0007I8-MD for qemu-devel@nongnu.org; Mon, 05 Jul 2010 13:46:07 -0400 Message-ID: <4C321A50.3030908@redhat.com> Date: Mon, 05 Jul 2010 20:45:52 +0300 From: Avi Kivity 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> <4C31CD38.5050904@siemens.com> <4C31CED1.70704@redhat.com> <4C31DE17.9090802@siemens.com> <4C31E276.7010801@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , Paul Brook , Gleb Natapov , "qemu-devel@nongnu.org" On 07/05/2010 08:12 PM, Blue Swirl wrote: > > Since you seem to have gone back to drawing board, how about the > following design: > > Explicit qemu_irqs and muxes for the backwards channel > > [...] The question of how to design the thing is secondary to me, at present. IMO the first question we have to answer is whether we track interrupts by delivery (queued into the core/apic, coalesced by core/apic, or masked at the irq controller) or mask/ack (masked before the core, or acknowledged by guest software; coalescing can be derived from nr_irq > nr_acks). The two approaches provide different information, I don't currently have a feel for which is better. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.