| Message ID | 1329860377-6284-10-git-send-email-alevy@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 02/21/12 22:39, Alon Levy wrote: > This changes the behavior of the monitor command. After the previous > patch, there is no longer an option of deadlock with virt-manager, but > ppm_save is called too early, before the update has completed. With this > patch it is called at the correct moment, but that means there is a race > between the monitor command completing and the screendump file being saved. > > The only solution is to use an asynchronous monitor command. For a > previous round of this see: > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > Since that's contentious, I'm suggesting we do something that is almost > correct and doesn't hang, instead of correct and hangs. The screendump > user can inotify on the directory and the file if need be. For casual > monitor usage there is no difference. I still think we should defer that and figure how to fix that properly, either using (internally) async monitor commands via qapi, or using an event. > +typedef struct QXLPPMSaveBHData { > + PCIQXLDevice *qxl; > + QXLCookie *cookie; > +} QXLPPMSaveBHData; Is there a need for a separate struct? I think you can just stick the filename into the QXLCookie struct, then write out screen shots in the update area bottom half, no? cheers, Gerd
On Wed, Feb 22, 2012 at 12:46:28PM +0100, Gerd Hoffmann wrote: > On 02/21/12 22:39, Alon Levy wrote: > > This changes the behavior of the monitor command. After the previous > > patch, there is no longer an option of deadlock with virt-manager, but > > ppm_save is called too early, before the update has completed. With this > > patch it is called at the correct moment, but that means there is a race > > between the monitor command completing and the screendump file being saved. > > > > The only solution is to use an asynchronous monitor command. For a > > previous round of this see: > > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > > > Since that's contentious, I'm suggesting we do something that is almost > > correct and doesn't hang, instead of correct and hangs. The screendump > > user can inotify on the directory and the file if need be. For casual > > monitor usage there is no difference. > > I still think we should defer that and figure how to fix that properly, > either using (internally) async monitor commands via qapi, or using an > event. > > > +typedef struct QXLPPMSaveBHData { > > + PCIQXLDevice *qxl; > > + QXLCookie *cookie; > > +} QXLPPMSaveBHData; > > Is there a need for a separate struct? I think you can just stick the > filename into the QXLCookie struct, then write out screen shots in the > update area bottom half, no? You don't get the cookie in the update_area bottom half. It's solemnly for update_area_complete. It's not easy to associate a cookie with it, since it may be called by the server without previous provocation from qemu. I'll take another look. > > cheers, > Gerd > >
On Wed, Feb 22, 2012 at 12:46:28PM +0100, Gerd Hoffmann wrote: > On 02/21/12 22:39, Alon Levy wrote: > > This changes the behavior of the monitor command. After the previous > > patch, there is no longer an option of deadlock with virt-manager, but > > ppm_save is called too early, before the update has completed. With this > > patch it is called at the correct moment, but that means there is a race > > between the monitor command completing and the screendump file being saved. > > > > The only solution is to use an asynchronous monitor command. For a > > previous round of this see: > > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > > > Since that's contentious, I'm suggesting we do something that is almost > > correct and doesn't hang, instead of correct and hangs. The screendump > > user can inotify on the directory and the file if need be. For casual > > monitor usage there is no difference. > > I still think we should defer that and figure how to fix that properly, > either using (internally) async monitor commands via qapi, or using an > event. I'm looking at QAPI. But in general I think it's better to have a correct image then a timely image. Without this patch you get an old image, unless you do what autotest does and request one every few seconds, then you won't really notice the difference (it would be one frame offset, kinda). > > > +typedef struct QXLPPMSaveBHData { > > + PCIQXLDevice *qxl; > > + QXLCookie *cookie; > > +} QXLPPMSaveBHData; > > Is there a need for a separate struct? I think you can just stick the > filename into the QXLCookie struct, then write out screen shots in the > update area bottom half, no? > > cheers, > Gerd >
On Wed, Feb 22, 2012 at 12:46:28PM +0100, Gerd Hoffmann wrote: > On 02/21/12 22:39, Alon Levy wrote: > > This changes the behavior of the monitor command. After the previous > > patch, there is no longer an option of deadlock with virt-manager, but > > ppm_save is called too early, before the update has completed. With this > > patch it is called at the correct moment, but that means there is a race > > between the monitor command completing and the screendump file being saved. > > > > The only solution is to use an asynchronous monitor command. For a > > previous round of this see: > > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > > > Since that's contentious, I'm suggesting we do something that is almost > > correct and doesn't hang, instead of correct and hangs. The screendump > > user can inotify on the directory and the file if need be. For casual > > monitor usage there is no difference. > > I still think we should defer that and figure how to fix that properly, > either using (internally) async monitor commands via qapi, or using an > event. > > > +typedef struct QXLPPMSaveBHData { > > + PCIQXLDevice *qxl; > > + QXLCookie *cookie; > > +} QXLPPMSaveBHData; > > Is there a need for a separate struct? I think you can just stick the > filename into the QXLCookie struct, then write out screen shots in the > update area bottom half, no? The bh is there so I don't have to reset the opaque for the update_area bh - only way to do that is to create a new bh everytime, since there can be multiple update_area bh's scheduled at the same time. The struct can go, if I change qxl -> qxl0, which I guess is fine for this command. > > cheers, > Gerd > >
diff --git a/hw/qxl-render.c b/hw/qxl-render.c index 23e6929..4b34c6f 100644 --- a/hw/qxl-render.c +++ b/hw/qxl-render.c @@ -78,6 +78,11 @@ void qxl_render_resize(PCIQXLDevice *qxl) } } +typedef struct QXLPPMSaveBHData { + PCIQXLDevice *qxl; + QXLCookie *cookie; +} QXLPPMSaveBHData; + static void qxl_render_clear_update_redraw_unlocked(PCIQXLDevice *qxl) { qxl->render_update_redraw = 0; @@ -86,6 +91,33 @@ static void qxl_render_clear_update_redraw_unlocked(PCIQXLDevice *qxl) qxl->num_dirty_rects = 0; } +static void qxl_render_ppm_save_bh(void *opaque) +{ + QXLPPMSaveBHData *data = opaque; + PCIQXLDevice *qxl = data->qxl; + QXLCookie *cookie = data->cookie; + QEMUBH *bh = cookie->u.render.ppm_save_bh; + QXLRect area = { + .left = 0, + .right = qxl->guest_primary.surface.width, + .top = 0, + .bottom = qxl->guest_primary.surface.height + }; + + qemu_mutex_lock(&qxl->ssd.lock); + dprint(qxl, 1, "%s: %p (primary %p)\n", __func__, + qxl->ssd.ds->surface->data, qxl->guest_primary.data); + qxl_flip(qxl, &area); + qxl_render_clear_update_redraw_unlocked(qxl); + ppm_save(cookie->u.render.filename, qxl->ssd.ds->surface); + g_free(cookie->u.render.filename); + g_free(cookie); + --qxl->render_update_cookie_num; + g_free(data); + qemu_mutex_unlock(&qxl->ssd.lock); + qemu_bh_delete(bh); +} + static void qxl_displaysurface_resize(PCIQXLDevice *qxl) { VGACommonState *vga = &qxl->vga; @@ -143,16 +175,17 @@ static void qxl_render_update_area_unlocked(PCIQXLDevice *qxl) * callbacks are called by spice_server thread, defering to bh called from the * io thread. */ -void qxl_render_update(PCIQXLDevice *qxl) +void qxl_render_update(PCIQXLDevice *qxl, const char *filename) { int redraw = 0; QXLCookie *cookie; + QEMUBH *ppm_save_bh; + QXLPPMSaveBHData *ppm_save_bh_data; qemu_mutex_lock(&qxl->ssd.lock); if (qxl->guest_primary.resized) { qxl->guest_primary.resized = 0; - qxl->guest_primary.data = memory_region_get_ram_ptr(&qxl->vga.vram); dprint(qxl, 1, "%s: %dx%d, stride %d, bpp %d, depth %d\n", __FUNCTION__, @@ -165,6 +198,12 @@ void qxl_render_update(PCIQXLDevice *qxl) } if (!qxl->guest_primary.commands) { + if (filename) { + dprint(qxl, 1, "%s: screendump with no pending commands\n", + __func__); + qxl_render_update_area_unlocked(qxl); + ppm_save(filename, qxl->ssd.ds->surface); + } qemu_mutex_unlock(&qxl->ssd.lock); return; } @@ -177,6 +216,14 @@ void qxl_render_update(PCIQXLDevice *qxl) cookie->u.render.area.top = 0; cookie->u.render.area.bottom = qxl->guest_primary.surface.height; qxl->render_update_redraw_area = cookie->u.render.area; + if (filename) { + ppm_save_bh_data = g_malloc0(sizeof(*ppm_save_bh_data)); + ppm_save_bh_data->qxl = qxl; + ppm_save_bh_data->cookie = cookie; + ppm_save_bh = qemu_bh_new(qxl_render_ppm_save_bh, ppm_save_bh_data); + cookie->u.render.filename = g_strdup(filename); + cookie->u.render.ppm_save_bh = ppm_save_bh; + } qxl->render_update_cookie_num++; qemu_mutex_unlock(&qxl->ssd.lock); qxl_spice_update_area(qxl, 0, &cookie->u.render.area, NULL, @@ -202,9 +249,14 @@ void qxl_render_update_area_bh(void *opaque) void qxl_render_update_area_done(PCIQXLDevice *qxl, QXLCookie *cookie) { qemu_mutex_lock(&qxl->ssd.lock); - qxl->render_update_cookie_num--; + if (cookie->u.render.filename) { + dprint(qxl, 1, "%s: scheduling ppm_save_bh\n", __func__); + qemu_bh_schedule(cookie->u.render.ppm_save_bh); + } else { + --qxl->render_update_cookie_num; + g_free(cookie); + } qemu_mutex_unlock(&qxl->ssd.lock); - g_free(cookie); } static QEMUCursor *qxl_cursor(PCIQXLDevice *qxl, QXLCursor *cursor) diff --git a/hw/qxl.c b/hw/qxl.c index b4f84f2..82f9ffa 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -1480,7 +1480,7 @@ static void qxl_hw_update(void *opaque) break; case QXL_MODE_COMPAT: case QXL_MODE_NATIVE: - qxl_render_update(qxl); + qxl_render_update(qxl, NULL); break; default: break; @@ -1502,8 +1502,15 @@ static void qxl_hw_screen_dump(void *opaque, const char *filename) switch (qxl->mode) { case QXL_MODE_COMPAT: case QXL_MODE_NATIVE: - qxl_render_update(qxl); - ppm_save(filename, qxl->ssd.ds->surface); + /* + * TODO: if we use an async update_area, to avoid deadlock with + * virt-manager, we postpone the saving of the image until the + * rendering is done. This means the image isn't guranteed to be + * written when we return to the monitor. Fixing this needs an async + * monitor command, whatever the implementation of the concept is + * called. + */ + qxl_render_update(qxl, filename); break; case QXL_MODE_VGA: /* diff --git a/hw/qxl.h b/hw/qxl.h index 57a94ca..91297bd 100644 --- a/hw/qxl.h +++ b/hw/qxl.h @@ -138,7 +138,7 @@ void qxl_log_command(PCIQXLDevice *qxl, const char *ring, QXLCommandExt *ext); /* qxl-render.c */ void qxl_render_resize(PCIQXLDevice *qxl); -void qxl_render_update(PCIQXLDevice *qxl); +void qxl_render_update(PCIQXLDevice *qxl, const char *filename); void qxl_render_cursor(PCIQXLDevice *qxl, QXLCommandExt *ext); void qxl_render_update_area_done(PCIQXLDevice *qxl, QXLCookie *cookie); void qxl_render_update_area_bh(void *opaque); diff --git a/ui/spice-display.h b/ui/spice-display.h index 81fa1e4..076e0e5 100644 --- a/ui/spice-display.h +++ b/ui/spice-display.h @@ -62,6 +62,8 @@ typedef struct QXLCookie { struct { QXLRect area; int redraw; + char *filename; + QEMUBH *ppm_save_bh; } render; } u; } QXLCookie;
This changes the behavior of the monitor command. After the previous patch, there is no longer an option of deadlock with virt-manager, but ppm_save is called too early, before the update has completed. With this patch it is called at the correct moment, but that means there is a race between the monitor command completing and the screendump file being saved. The only solution is to use an asynchronous monitor command. For a previous round of this see: http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html Since that's contentious, I'm suggesting we do something that is almost correct and doesn't hang, instead of correct and hangs. The screendump user can inotify on the directory and the file if need be. For casual monitor usage there is no difference. Signed-off-by: Alon Levy <alevy@redhat.com> --- hw/qxl-render.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++--- hw/qxl.c | 13 ++++++++-- hw/qxl.h | 2 +- ui/spice-display.h | 2 + 4 files changed, 69 insertions(+), 8 deletions(-)