From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO33u-0007D6-Vp for qemu-devel@nongnu.org; Thu, 13 Mar 2014 06:40:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WO33i-0000Yp-Ox for qemu-devel@nongnu.org; Thu, 13 Mar 2014 06:40:30 -0400 Received: from mail-ee0-x230.google.com ([2a00:1450:4013:c00::230]:49196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WO33i-0000Yi-Ho for qemu-devel@nongnu.org; Thu, 13 Mar 2014 06:40:18 -0400 Received: by mail-ee0-f48.google.com with SMTP id e51so323725eek.7 for ; Thu, 13 Mar 2014 03:40:17 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53218B0D.8000405@redhat.com> Date: Thu, 13 Mar 2014 11:40:13 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1394628914-10758-1-git-send-email-kraxel@redhat.com> <1394628914-10758-4-git-send-email-kraxel@redhat.com> <20140312202611.GB3004@redhat.com> In-Reply-To: <20140312202611.GB3004@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Gerd Hoffmann Cc: airlied@redhat.com, qemu-devel@nongnu.org, Anthony Liguori Il 12/03/2014 21:26, Michael S. Tsirkin ha scritto: >> +Event queue: >> +The only current event passed is a message to denote the host >> +wants to update the layout of the screens. It contains the same >> +info as the response to VIRTGPU_CMD_GET_DISPLAY_INFO. I wonder if an event queue is the best mechanism if you can get the same info from a command anyway. For virtio-scsi I used a queue because I needed to specify which target or LUN the event applied to, but here you do not need it and a queue is susceptible to dropped events. Perhaps a configuration field is better, like this: u32 events_read; u32 events_clear; A new event sets a bit in events_read and generates a configuration change interrupt. The guest should never write to events_read. Writing to events_clear has the side effect of the device doing "events_read &= ~events_clear". We cannot have R/W1C fields in virtio, but this approximation is good enough. When the guest receives a configuration change interrupt, it reads event_read. If it is nonzero, it writes the same value it read to events_clear, and sends the necessary commands to the card in order to retrieve the event data. It can then read again event_read, and loop if it is again nonzero. Paolo