From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQRM-0005w5-C0 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:23:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBQRI-0005ZB-29 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:23:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBQRH-0005YC-OC for qemu-devel@nongnu.org; Tue, 11 Sep 2012 09:23:39 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8BDNd6V006970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Sep 2012 09:23:39 -0400 Message-ID: <504F3BA2.20306@redhat.com> Date: Tue, 11 Sep 2012 15:24:50 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1221316208.33090140.1347368736495.JavaMail.root@redhat.com> In-Reply-To: <1221316208.33090140.1347368736495.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Alon Levy Cc: Gerd Hoffmann , qemu-devel@nongnu.org Hi, On 09/11/2012 03:05 PM, Alon Levy wrote: >>> 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..). Right, thinking more about this, this means that the don't send it to the agent when QXL_INTERRUPT_CLIENT_MONITORS_CONFIG is set in mask trick won't work, for windows with an older driver. I suggest rather then doing the whole capabilities dance, we simply detect the (older) windows driver (mask == ~0), and then treat that as QXL_INTERRUPT_CLIENT_MONITORS_CONFIG not being set in mask, a bit of hack but still much simpler then adding a full capabilities interface. If windows ever wants to actually support CLIENT_MONITORS_CONFIG through the driver rather then trough the agent, the driver will need updating anyways and we can then drop the ~0 replacing it with the proper mask. Regards, Hans