From: Marc-André Lureau <marcandre.lureau@redhat.com>

Hi,

Thanks to recent work by Kevin, it becomes possible to run HMP/QMP commands i=
n a
coroutine. The screendump command is a good target, as it requires to re-enter
the main-loop in ordre to flush the display, and write to file in a non-block=
ing
way.

Despite the flush, the dump may still have glitches. The graphic device may
perform some operations during the write on the same framebuffer. Doing a mem=
ory
copy could help, but it would also create a number of other issues. Keeping t=
he
BQL would defeat a number of advantages of using a coroutine. Afaik, there is=
 no
mechanism to "freeze" the device either (and this could also have bad
consequences anyway). Good enough?

Marc-Andr=C3=A9 Lureau (3):
  coroutine: let CoQueue wake up outside a coroutine
  console: modify ppm_save to take a pixman image ref
  console: make QMP/HMP screendump run in coroutine

 hmp-commands.hx            |  1 +
 monitor/hmp-cmds.c         |  3 ++-
 qapi/ui.json               |  3 ++-
 ui/console.c               | 42 +++++++++++++++++++++++++++++---------
 ui/trace-events            |  2 +-
 util/qemu-coroutine-lock.c |  6 ++----
 6 files changed, 40 insertions(+), 17 deletions(-)

--=20
2.28.0

  Hi,

> Despite the flush, the dump may still have glitches. The graphic
> device may perform some operations during the write on the same
> framebuffer.

That problem exists anyway, even without coroutines.  The guest can
write to vga memory in parallel to iothread writing out the screen
dump.

> Good enough?

I'd say yes.  console bits are:

Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>

I can take that through ui patch queue, but want an ack from someone who
knows coroutines better than me for that.  Merging through some other
queue (monitor?) is fine with me too.

take care,
  Gerd

marcandre.lureau@redhat.com writes:

> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> Hi,
>
> Thanks to recent work by Kevin, it becomes possible to run HMP/QMP commands i=
> n a
> coroutine. The screendump command is a good target, as it requires to re-enter
> the main-loop in ordre to flush the display, and write to file in a non-block=
> ing
> way.
>
> Despite the flush, the dump may still have glitches. The graphic device may
> perform some operations during the write on the same framebuffer. Doing a mem=
> ory
> copy could help, but it would also create a number of other issues. Keeping t=
> he
> BQL would defeat a number of advantages of using a coroutine. Afaik, there is=
>  no
> mechanism to "freeze" the device either (and this could also have bad
> consequences anyway). Good enough?

This is v2 of
Message-Id: <20200113144848.2168018-1-marcandre.lureau@redhat.com>
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg02313.html

The title has become slightly misleading: v2 covers HMP, too, as the
description says.

A changelog would've helped me review.  Next time :)

[...]