From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPiz-0006gz-6S for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:37:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPip-0006w4-Ko for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:37:53 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:54841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPip-0006vt-6p for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:37:43 -0400 Date: Tue, 11 Sep 2012 08:37:42 -0400 (EDT) From: Alon Levy Message-ID: <302798009.33074692.1347367062562.JavaMail.root@redhat.com> In-Reply-To: <504F2D42.7020502@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 > Hi, > > > This will need spice-server <-> qemu/hw/qxl.c coordination, but I > > assume we > > will need some changes there anyway to set > > QXL_INTERRUPT_CLIENT_MONITORS_CONFIG, > > the qemu/hw/qxl.c function patching the MonitorsConfig into the > > romspace, > > and setting the irq in int_pending, could return whether or not the > > flag > > was > > set in int_mask for example. > > Yes, interface_client_monitors_config() can return whenever the guest > has masked the interrupt or not, and based on that spice-server can > send > the message to the agent or not. 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). > > cheers, > Gerd > > >