| Message ID | 20201010204106.1368710-1-marcandre.lureau@redhat.com |
|---|---|
| Headers | show |
| Series | console: make QMP screendump use coroutine | expand |
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> > > The function is going to be called from a coroutine, and may yields. s/yields/yield/ > Let's ensure our image reference doesn't change over time (due to resize > etc) by keeping a ref. > > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
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 :) [...]
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