From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JdnAV-0003oA-Nk for qemu-devel@nongnu.org; Mon, 24 Mar 2008 09:56:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JdnAU-0003ny-QF for qemu-devel@nongnu.org; Mon, 24 Mar 2008 09:56:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JdnAU-0003nv-MC for qemu-devel@nongnu.org; Mon, 24 Mar 2008 09:56:54 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JdnAT-0002h7-Eb for qemu-devel@nongnu.org; Mon, 24 Mar 2008 09:56:54 -0400 Message-ID: <47E7B303.2050100@qumranet.com> Date: Mon, 24 Mar 2008 15:56:19 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support References: <1206282453.18800.31.camel@localhost.localdomain> <200803231619.32472.paul@codesourcery.com> <47E7542C.60901@qumranet.com> <200803241345.29197.paul@codesourcery.com> In-Reply-To: <200803241345.29197.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: kvm-devel , qemu-devel@nongnu.org Paul Brook wrote: > On Monday 24 March 2008, Avi Kivity wrote: > >> Paul Brook wrote: >> >>> On Sunday 23 March 2008, Dor Laor wrote: >>> >>>> --- a/qemu/hw/irq.c >>>> +++ b/qemu/hw/irq.c >>>> @@ -30,6 +30,8 @@ struct IRQState { >>>> int n; >>>> }; >>>> >>>> +uint32_t qemu_irq_acked[NR_IRQ_WORDS]; >>>> >>> This is absolute rubbish. The whole point of the IRQ framework is that it >>> doesn't assume a single flat IRQ controller. >>> >> x86 does have a single irq space (even when using cascaded pics or >> multiple ioapics), called gsi (for generalized system interrupt, or >> something). It is possible to enumerate all irqs on all platforms that >> have a finite number of them. >> > > Sure, it's possible to enumerate all the possible IRQ inputs (it's effectively > the same as enumerating all the IRQ sources). It's not possible to say > anything particularly useful about that enumeration though. > It's not uncommon for interrupts to be connected to GPIO pins, be inverted, or > have interrupt routings that change dynamically. > > Right, but... >> It may be better though to identify an irq by a (controller_id, >> irq_line) pair instead. >> > > That's what qemu_irq is for. Anything else is IMHO wrong. > In the case of a kernel virtualization module (like kqemu of kvm) that is able to handle interrupt injection, qemu_irq is not sufficient since it is not visible to the kernel. We need some serialization that can pass the user/kernel boundary. For x86 gsi is a satisfactory serialization. Even for a pure qemu solution, qemu_irq is difficult to work with. For the x86 case, we know which vector was successfully injected, and we need to work out which qemu_irq caused it. This is not deterministic in the general case (since several irq lines can cause the same vector to be injected, and since the irq->vector mapping can change), so any solution will involve heuristics. -- error compiling committee.c: too many arguments to function