From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQ9v-0007WP-Ru for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:05:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBQ9p-0008Du-SH for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:05:43 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:53763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQ9p-0008Dm-K9 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:05:37 -0400 Date: Tue, 11 Sep 2012 09:05:36 -0400 (EDT) From: Alon Levy Message-ID: <1221316208.33090140.1347368736495.JavaMail.root@redhat.com> In-Reply-To: <504F36AD.9080308@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] hw/qxl: support client monitor configuration via device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Hans de Goede , qemu-devel@nongnu.org > > ok, I'm missing something here. (and trying to catch up via Vol 3A > > is taking too long). > > I thought the order is: > > (1) qemu raises interrupt > > (2) qemu calls kvm ioctl > > (3) guest interrupt handler > > (4) guest clears interrupt by writing ~0 to qxl > > ram_header->int_mask. > > (5) qemu detects this next time it raises interrupt. > > > so where does qemu/hw/qxl.c get a chance to see this masking > > *immediately* after it raises the interrupt, i.e. before (2) above, > > since otherwise there is a timeout here, you need to add a > > callback, > > it gets complicated, and then the unconditional two way sending > > looks > > much better. (I'm already on the same page with you on not needing > > guest capabilities at this point, even though for the future it did > > look like a good thing to have). > > There are two registers: > > (1) the interrupt enable register (aka ram->int_mask) > (2) the interrupt status register (aka ram->int_pending) > > qemu sets the irq bit in the status register each time the irq > condition > is meet. qemu actually raises an irq in case the guest has the irq > bit > set in the enable register. guest acks the irq by clearing the irq > bit > in the status register (then issue QXL_IO_UPDATE_IRQ to notify qemu > that > it touched interrupt registers, which we need because our registers > in > memory not mmio space). > > So qxl can simply look at the enable register bit to figure whenever > the > guest is interested in specific interrupts or not. Hans and myself discussed offline the current windows driver implementation. In short, it sets ram->int_mask to ~0, thereby claiming to support all 32 interrupts (including those we haven't thought of yet..). > > cheers, > Gerd > >