From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50899 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OVm1S-0004Dr-Rt for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:47:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OVm1R-0005WC-PF for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:47:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52489) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OVm1R-0005W2-FJ for qemu-devel@nongnu.org; Mon, 05 Jul 2010 09:47:45 -0400 Message-ID: <4C31E276.7010801@redhat.com> Date: Mon, 05 Jul 2010 16:47:34 +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> In-Reply-To: <4C31DE17.9090802@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , Paul Brook , Gleb Natapov , "qemu-devel@nongnu.org" On 07/05/2010 04:28 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 07/05/2010 03:16 PM, Jan Kiszka wrote: >> >>>> 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. >>> >> Usually, when that happens, we get an obscure bug. >> >> So if we add a facility, especially across the user/kernel boundary, >> it's better to have it conform to the architecture. That reduces the >> chance it has a serious hidden bug. >> > Neither ack/mask notifiers (past the IRQ controller) nor injection > return values are part of any architecture we emulate. Right. But placing a tap on something that exists architectually means it's likely to survive implementation changes. > What is driving > us are the requirements of the de-coalescing workarounds we want to > build on top and the impact on existing design. > In the case of qemu<->kvm interfaces, also the longevity of these interfaces. Note I'm not advocating a mask/ack solution. It's pretty complicated and I'm not sure the benefits outweigh the complexity. But I want us to examine all options, especially as I don't like delivery checks very much. >>> The abstraction is always an IRQ line which can be >>> high or low (sometimes it is only high, but this is a bug). >>> >>> >> That's a bug in the use of qemu_irq, not qemu_irq itself. >> >> But qemu_irq needs to remember its state, otherwise when an irq >> controller unmasks a level-triggered line, it won't see the interrupt. >> > I think it's currently the IRQ controller's job to keep track of the > line state during masked periods. Moving this to qemu_irq is definitely > better but requires some care (e.g. when vmstates are involved). > If everything is done correctly no new vmstates are needed. The irq producer, when its state is reloaded, will output exactly the same value as when the state was saved. The irq line qemu_irq models doesn't have a flip-flop, so it doesn't have state. Similarly, the irq inputs on the irq controllers don't have flip flops attached (some do), so ioapic->irr for example shouldn't be state. (some care is needed on load to avoid spurious edges) -- error compiling committee.c: too many arguments to function