From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzSQ0-0006wB-Qk for qemu-devel@nongnu.org; Mon, 20 Feb 2012 07:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzSPy-0003IV-Vx for qemu-devel@nongnu.org; Mon, 20 Feb 2012 07:32:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzSPy-0003IQ-OH for qemu-devel@nongnu.org; Mon, 20 Feb 2012 07:32:34 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1KCWYaT013717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Feb 2012 07:32:34 -0500 Date: Mon, 20 Feb 2012 14:32:29 +0200 From: Alon Levy Message-ID: <20120220123229.GE23926@garlic.redhat.com> References: <1329686886-6853-1-git-send-email-alevy@redhat.com> <1329686886-6853-5-git-send-email-alevy@redhat.com> <4F422A2E.3020106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F422A2E.3020106@redhat.com> Subject: Re: [Qemu-devel] [RFC 4/7] qxl: make qxl_render_update async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, elmarco@redhat.com On Mon, Feb 20, 2012 at 12:10:38PM +0100, Gerd Hoffmann wrote: > Hi, > > > > +void qxl_render_update_area_done(PCIQXLDevice *qxl, QXLCookie *cookie) > > +{ > > This is called from spice server thread context, correct? > > > - for (i = 0; i < ARRAY_SIZE(dirty); i++) { > > + for (i = 0; i < ARRAY_SIZE(data->dirty); i++) { > > if (qemu_spice_rect_is_empty(dirty+i)) { > > break; > > } > > @@ -151,6 +171,7 @@ void qxl_render_update(PCIQXLDevice *qxl) > > dpy_update() call here. Calling that one isn't safe without grabbing > the qemu lock. About dpy_update, discovered it the hard way. You mean I need the lock for dpy_update or also before? > > > dirty[i].right - dirty[i].left, > > dirty[i].bottom - dirty[i].top); > > } > > > @@ -145,15 +145,19 @@ void qxl_spice_update_area(PCIQXLDevice *qxl, uint32_t surface_id, > > uint32_t clear_dirty_region, > > qxl_async_io async, QXLCookie *cookie) > > { > > + struct QXLRect *area_copy; > > if (async == QXL_SYNC) { > > qxl->ssd.worker->update_area(qxl->ssd.worker, surface_id, area, > > dirty_rects, num_dirty_rects, clear_dirty_region); > > } else { > > #if SPICE_INTERFACE_QXL_MINOR >= 1 > > if (cookie == NULL) { > > + area_copy = g_malloc0(sizeof(*area_copy)); > > + memcpy(area_copy, area, sizeof(*area)); > > + area = area_copy; > > cookie = qxl_cookie_new(QXL_COOKIE_TYPE_IO, > > QXL_IO_UPDATE_AREA_ASYNC, > > - 0); > > + (uint64_t)area_copy); > > I still think this is the wrong place. Yes, I agree, I thought I removed this already, I'll fix. > > Also: How about making removing QXLCookie->data and adding a union > instead? It's not like we have to transparently pass through a pointer > for someone else, it's our own state data, so this extra indirection > doesn't make sense at all. ok, will do. > > cheers, > Gerd >