All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [PATCH] console: make QMP screendump use coroutine
Date: Thu, 05 Mar 2020 15:41:50 +0100	[thread overview]
Message-ID: <87a74ueudt.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200113144848.2168018-1-marcandre.lureau@redhat.com> ("Marc-André Lureau"'s message of "Mon, 13 Jan 2020 18:48:48 +0400")

I tried to observe the main loop keeps running while the screendump does
its work.

The main loop appears to lack trace points.  Alright, if there's no
hammer handy, I'll use a rock:

diff --git a/softmmu/vl.c b/softmmu/vl.c
index 5549f4b619..b6561a65d7 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1661,6 +1661,7 @@ void qemu_main_loop(void)
 #ifdef CONFIG_PROFILER
         ti = profile_getclock();
 #endif
+        printf("*** main loop\n");
         main_loop_wait(false);
 #ifdef CONFIG_PROFILER
         dev_time += profile_getclock() - ti;


First experiment: does the main loop continue to run when writing out
the screendump blocks / would block?

Observe qmp_screendump() opens the file without O_EXCL.  Great, that
lets me block output by making it open a FIFO.

Terminal#1:

    $ mkfifo s

Terminal#2:

    $ upstream-qemu -S -display none -chardev socket,id=qmp,path=test-qmp,server=on,wait=off -mon mode=control,chardev=qmp
    *** main loop
    *** main loop
    *** main loop

Keeps printing at a steady pace.

Terminal#3:

    $ socat "READLINE,history=$HOME/.qmp_history,prompt=QMP>" UNIX-CONNECT:$HOME/work/images/test-qmp 
    {"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 4}, "package": "v4.2.0-2069-g5e5ae6b644-dirty"}, "capabilities": ["oob"]}}
    QMP>{"execute": "qmp_capabilities"}
    {"return": {}}
    QMP>{"execute": "screendump", "arguments": {"filename": "s"}}

The printing in terminal#2 stops.  This is expected; qemu_open() calls
open(), which blocks, because the FIFO has no reader.

Terminal#1:

    $ exec 4<s

Now the FIFO has a reader.  Terminal#2 remains quiet.

We now hang in ppm_save().  Abridged stack backtrace:

    #0  0x00007ffff519d0f5 in writev () at /lib64/libc.so.6
    #1  0x0000555555e15f61 in qio_channel_file_writev
        (ioc=0x5555567bf5f0, iov=0x555556a441b0, niov=1, fds=0x0, nfds=0, errp=0x7fffe9d81d10) at /work/armbru/qemu/io/channel-file.c:123
    #2  0x0000555555e133d3 in qio_channel_writev_full
        (ioc=0x5555567bf5f0, iov=0x555556a441b0, niov=1, fds=0x0, nfds=0, errp=0x7fffe9d81d10) at /work/armbru/qemu/io/channel.c:86
    #3  0x0000555555e137a2 in qio_channel_writev
        (ioc=0x5555567bf5f0, iov=0x555556a441b0, niov=1, errp=0x7fffe9d81d10)
        at /work/armbru/qemu/io/channel.c:207
    #4  0x0000555555e13696 in qio_channel_writev_all
        (ioc=0x5555567bf5f0, iov=0x7fffe9d81bd0, niov=1, errp=0x7fffe9d81d10)
        at /work/armbru/qemu/io/channel.c:171
    #5  0x0000555555e139b1 in qio_channel_write_all
        (ioc=0x5555567bf5f0, buf=0x555556b05200 "", buflen=1920, errp=0x7fffe9d81d10) at /work/armbru/qemu/io/channel.c:257
    #6  0x0000555555cd74ff in ppm_save
        (fd=22, image=0x5555568ffdd0, errp=0x7fffe9d81d10)
        at /work/armbru/qemu/ui/console.c:336
    #7  0x0000555555cd77e6 in qmp_screendump
        (filename=0x555556ea0900 "s", has_device=false, device=0x0, has_head=false, head=0, errp=0x7fffe9d81d10) at /work/armbru/qemu/ui/console.c:401

A brief inspection of qio_channel_file_writev() and
qio_channel_writev_all() suggests this might work if you make the output
file descriptor non-blocking.

    $ head -c 1 <&4 | hexdump -C
    00000000  50                                                |P|
    00000001

Still quiet.

    $ cat <&4 >/dev/null

The printing resumes.

    $ exec 4<&-


Second experiment: does the main loop continue to run while we wait for
graphic_hw_update_done()?

Left as an exercise for the patch submitter ;)



  parent reply	other threads:[~2020-03-05 14:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 14:48 [PATCH] console: make QMP screendump use coroutine Marc-André Lureau
2020-01-13 16:32 ` no-reply
2020-01-13 16:36 ` no-reply
2020-02-12 12:29 ` Gerd Hoffmann
2020-02-13 13:10   ` Markus Armbruster
2020-02-20  7:48 ` Markus Armbruster
2020-02-20  9:43   ` Marc-André Lureau
2020-02-20 16:01     ` Markus Armbruster
2020-02-20 20:11       ` Dr. David Alan Gilbert
2020-02-21  6:31         ` Markus Armbruster
2020-02-21 10:25           ` Dr. David Alan Gilbert
2020-02-21 10:07       ` Kevin Wolf
2020-02-21 16:50         ` Markus Armbruster
2020-02-24 16:20           ` Marc-André Lureau
2020-03-02 14:22             ` Markus Armbruster
2020-03-02 15:36               ` Kevin Wolf
2020-03-03  7:41                 ` Markus Armbruster
2020-03-03 10:56                   ` Marc-André Lureau
2020-03-03 14:47                     ` Markus Armbruster
2020-03-03 16:03                   ` Marc-André Lureau
2020-03-06  8:44                     ` Markus Armbruster
2020-03-06 10:03                       ` Marc-André Lureau
2020-03-11 12:16                         ` Markus Armbruster
2020-03-05 14:41 ` Markus Armbruster [this message]
2020-03-05 15:08   ` Marc-André Lureau
2020-03-06  5:56     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a74ueudt.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.