From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@gmail.com>,
QEMU <qemu-devel@nongnu.org>, "Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH] console: make QMP screendump use coroutine
Date: Fri, 21 Feb 2020 10:25:48 +0000 [thread overview]
Message-ID: <20200221102548.GA2931@work-vm> (raw)
In-Reply-To: <87k14ga1ud.fsf@dusky.pond.sub.org>
* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
>
> > * Markus Armbruster (armbru@redhat.com) wrote:
> [...]
> >> Collecting several users before building infrastructure makes sense when
> >> the design of the infrastructure isn't obvious, or when the need for it
> >> is in doubt.
> >>
> >> Neither is the case for running QMP handlers in a coroutine: QMP
> >> commands blocking the main loop is without doubt a problem we need to
> >> solve, and the way to solve it was obvious enough for Kevin to do it
> >> with one user: block_resize. A second one quickly followed: screendump.
> >>
> >> The only part that's different for HMP, I think, is "need".
> >>
> >> Is HMP blocking the main loop a problem?
> >>
> >> If yes, is it serious enough to justify solving it?
> >
> > I don't mind if HMP blocks for a small time while doing something, but
> > not if it can hang if the guest (or something else like it) misbehaves.
> > Not if it's something you might need to issue another command to recover
> > from.
>
> The issue isn't HMP being unavailable while a command executes. The
> issue is HMP stopping the main loop while a command executes.
>
> Stopping the main loop not only stops everything running there, it can
> also stop other threads when they synchronize with the main loop via the
> Big QEMU Lock.
Yep.
> The obvious example is a command accessing a remote filesystem. Special
> case: NFS with the hard option can hang indefinitely.
That I don't worry about too much for HMP; if your host is hosed, fix your host.
> screendump does that, and also waits for asynchronous gfx_update() with
> qxl devices. Networking again, with a different peer.
That I would worry about since that's probably got interactions with the
guest and spice, and all the type of things you might be trying to debug
or test.
> We already decided that QMP commands stopping the main loop is serious.
>
> To say it's not serious for HMP amounts to "don't do that then, use
> QMP". Which may be fair. Not for me to decide, though.
It's certainly more important for QMP; you don't want the main lock
being held for everyday type of interactions with management layers.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-02-21 10:26 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 [this message]
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
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=20200221102548.GA2931@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@gmail.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.