From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54424 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLAtG-00011Q-Ix for qemu-devel@nongnu.org; Sun, 06 Jun 2010 04:07:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLAtF-0004SL-C6 for qemu-devel@nongnu.org; Sun, 06 Jun 2010 04:07:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61289) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLAtF-0004SD-47 for qemu-devel@nongnu.org; Sun, 06 Jun 2010 04:07:29 -0400 Date: Sun, 6 Jun 2010 11:07:25 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback Message-ID: <20100606080725.GE2337@redhat.com> References: <4C074A72.3070507@web.de> <20100603063456.GM24302@redhat.com> <4C0752CB.9030701@web.de> <20100603070300.GN24302@redhat.com> <20100603070559.GO24302@redhat.com> <4C099471.3060507@web.de> <20100606071536.GA2337@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Jan Kiszka , qemu-devel@nongnu.org, Juan Quintela On Sun, Jun 06, 2010 at 07:39:49AM +0000, Blue Swirl wrote: > On Sun, Jun 6, 2010 at 7:15 AM, Gleb Natapov wrote: > > On Sat, Jun 05, 2010 at 02:04:01AM +0200, Jan Kiszka wrote: > >> > I'd like to also support EOI handling. When the guest clears the > >> > interrupt condtion, the EOI callback would be called. This could occ= ur > >> > much later than the IRQ delivery time. I'm not sure if we need the > >> > result code in that case. > >> > > >> > If any intermediate device (IOAPIC?) needs to be informed about eith= er > >> > delivery or EOI also, it could create a proxy message with its > >> > callbacks in place. But we need then a separate opaque field (in > >> > addition to payload) to store the original message. > >> > > >> > struct IRQMsg { > >> > =9ADeviceState *src; > >> > =9Avoid (*delivery_cb)(IRQMsg *msg, int result); > >> > =9Avoid (*eoi_cb)(IRQMsg *msg, int result); > >> > =9Avoid *src_opaque; > >> > =9Avoid *payload; > >> > }; > >> > >> Extending the lifetime of IRQMsg objects beyond the delivery call stack > >> means qemu_malloc/free for every delivery. I think it takes a _very_ > >> appealing reason to justify this. But so far I do not see any use case > >> for eio_cb at all. > >> > > I dislike use of eoi for reinfecting missing interrupts since > > it eliminates use of internal PIC/APIC queue of not yet delivered > > interrupts. PIC and APIC has internal queue that can handle two element= s: > > one is delivered, but not yet acked interrupt in isr and another is > > pending interrupt in irr. Using eoi callback (or ack notifier as it's > > called inside kernel) interrupt will be considered coalesced even if irr > > is cleared, but no ack was received for previously delivered interrupt. > > But ack notifiers actually has another use: device assignment. There is > > a plan to move device assignment from kernel to userspace and for that > > ack notifiers will have to be extended to userspace too. If so we can > > use them to do irq decoalescing as well. I doubt they should be part > > of IRQMsg though. Why not do what kernel does: have globally registered > > notifier based on irqchip/pin. >=20 > Because translation at IOAPIC may be lossy, IRQs from many devices > pointing to the same vector? With IRQMsg you know where a specific > message came from. The situation is different inside the kernel: it > manages both translation and registration, whereas in QEMU we could > only control registration. Configuring IOAPIC like that is against x86 architecture. OS will not be able to map from interrupt vector back to device. -- Gleb.