All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: stefanha@redhat.com, marcandre.lureau@gmail.com,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	dgilbert@redhat.com
Subject: Re: [PATCH v7 08/13] qapi: Add a 'coroutine' flag for commands
Date: Fri, 25 Sep 2020 17:37:07 +0200	[thread overview]
Message-ID: <20200925153707.GG5731@linux.fritz.box> (raw)
In-Reply-To: <87r1r4mlt5.fsf@dusky.pond.sub.org>

Am 14.09.2020 um 17:15 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > This patch adds a new 'coroutine' flag to QMP command definitions that
> > tells the QMP dispatcher that the command handler is safe to be run in a
> > coroutine.
> >
> > The documentation of the new flag pretends that this flag is already
> > used as intended, which it isn't yet after this patch. We'll implement
> > this in another patch in this series.
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > Reviewed-by: Markus Armbruster <armbru@redhat.com>
> > ---
> >  docs/devel/qapi-code-gen.txt            | 12 ++++++++++++
> >  include/qapi/qmp/dispatch.h             |  1 +
> >  tests/test-qmp-cmds.c                   |  4 ++++
> >  scripts/qapi/commands.py                | 10 +++++++---
> >  scripts/qapi/doc.py                     |  2 +-
> >  scripts/qapi/expr.py                    | 10 ++++++++--
> >  scripts/qapi/introspect.py              |  2 +-
> >  scripts/qapi/schema.py                  | 12 ++++++++----
> >  tests/qapi-schema/test-qapi.py          |  7 ++++---
> >  tests/qapi-schema/meson.build           |  1 +
> >  tests/qapi-schema/oob-coroutine.err     |  2 ++
> >  tests/qapi-schema/oob-coroutine.json    |  2 ++
> >  tests/qapi-schema/oob-coroutine.out     |  0
> >  tests/qapi-schema/qapi-schema-test.json |  1 +
> >  tests/qapi-schema/qapi-schema-test.out  |  2 ++
> >  15 files changed, 54 insertions(+), 14 deletions(-)
> >  create mode 100644 tests/qapi-schema/oob-coroutine.err
> >  create mode 100644 tests/qapi-schema/oob-coroutine.json
> >  create mode 100644 tests/qapi-schema/oob-coroutine.out
> >
> > diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
> > index f3e7ced212..36daa9b5f8 100644
> > --- a/docs/devel/qapi-code-gen.txt
> > +++ b/docs/devel/qapi-code-gen.txt
> > @@ -472,6 +472,7 @@ Syntax:
> >                  '*gen': false,
> >                  '*allow-oob': true,
> >                  '*allow-preconfig': true,
> > +                '*coroutine': true,
> >                  '*if': COND,
> >                  '*features': FEATURES }
> >  
> > @@ -596,6 +597,17 @@ before the machine is built.  It defaults to false.  For example:
> >  QMP is available before the machine is built only when QEMU was
> >  started with --preconfig.
> >  
> > +Member 'coroutine' tells the QMP dispatcher whether the command handler
> > +is safe to be run in a coroutine.
> 
> We need to document what exactly makes a command handler coroutine safe
> / unsafe.  We discussed this at some length in review of PATCH v4 1/4:
> 
>     Message-ID: <874kwnvgad.fsf@dusky.pond.sub.org>
>     https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg05015.html
> 
> I'd be willing to accept a follow-up patch, if that's more convenient
> for you.

Did we ever arrive at a conclusion for a good definition?

I mean I can give a definition like "it's coroutine safe if it results
in the right behaviour even when called in coroutine context", but
that's not really helpful.

FWIW, I would also have a hard time giving a much better definition than
this for thread safety.

> >                                     It defaults to false.  If it is true,
> > +the command handler is called from coroutine context and may yield while
> 
> Is it *always* called from coroutine context, or could it be called
> outside coroutine context, too?  I guess the former, thanks to PATCH 10,
> and as long as we diligently mark HMP commands that such call QMP
> handlers, like you do in PATCH 13.

Yes, it must *always* be called from coroutine context. This is the
reason why I included HMP after all, even though I'm really mostly just
interested in QMP.

> What's the worst than can happen when we neglect to mark such an HMP
> command?

When the command handler tries to yield and it's not in coroutine
context, it will abort(). If it never tries to yield, I think it would
just work - but of course, the ability to yield is the only reason why
you would want to run a command handler in a coroutine.

Kevin



  reply	other threads:[~2020-09-25 15:43 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 15:11 [PATCH v7 00/13] monitor: Optionally run handlers in coroutines Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 01/13] monitor: Add Monitor parameter to monitor_set_cpu() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 02/13] monitor: Add Monitor parameter to monitor_get_cpu_index() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 03/13] monitor: Use getter/setter functions for cur_mon Kevin Wolf
2020-10-02  7:51   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 04/13] hmp: Update current monitor only in handle_hmp_command() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 05/13] qmp: Assert that no other monitor is active Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 06/13] qmp: Call monitor_set_cur() only in qmp_dispatch() Kevin Wolf
2020-09-14 15:10   ` Markus Armbruster
2020-09-25 15:13     ` Kevin Wolf
2020-09-28 11:42       ` Markus Armbruster
2020-09-28 14:30         ` Kevin Wolf
2020-09-30  9:26           ` Markus Armbruster
2020-09-30 11:29             ` Kevin Wolf
2020-09-30 13:14               ` Markus Armbruster
2020-09-30 14:00                 ` Kevin Wolf
2020-09-30 17:20                   ` Dr. David Alan Gilbert
2020-10-01 10:14                     ` Kevin Wolf
2020-10-01 16:00                       ` Markus Armbruster
2020-10-02  8:04                         ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 07/13] monitor: Make current monitor a per-coroutine property Kevin Wolf
2020-09-14 15:11   ` Markus Armbruster
2020-09-25 15:23     ` Kevin Wolf
2020-09-28  7:47       ` Markus Armbruster
2020-09-28 10:42         ` Kevin Wolf
2020-09-28 12:21           ` Markus Armbruster
2020-10-02  7:53   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 08/13] qapi: Add a 'coroutine' flag for commands Kevin Wolf
2020-09-14 15:15   ` Markus Armbruster
2020-09-25 15:37     ` Kevin Wolf [this message]
2020-09-28  8:23       ` Markus Armbruster
2020-10-02  7:53   ` Markus Armbruster
2020-10-02  7:59   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 09/13] qmp: Move dispatcher to a coroutine Kevin Wolf
2020-09-14 15:30   ` Markus Armbruster
2020-09-25 15:38     ` Kevin Wolf
2020-09-28  8:24       ` Markus Armbruster
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 10/13] hmp: Add support for coroutine command handlers Kevin Wolf
2020-09-16  9:46   ` Dr. David Alan Gilbert
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 11/13] util/async: Add aio_co_reschedule_self() Kevin Wolf
2020-09-15 14:25   ` Stefan Hajnoczi
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 12/13] block: Add bdrv_co_move_to_aio_context() Kevin Wolf
2020-09-15 14:31   ` Stefan Hajnoczi
2020-09-25 16:00     ` Kevin Wolf
2020-09-28  8:59       ` Stefan Hajnoczi
2020-09-28 10:21         ` Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 13/13] block: Convert 'block_resize' to coroutine Kevin Wolf
2020-09-15 14:57   ` Stefan Hajnoczi
2020-09-25 16:07     ` Kevin Wolf
2020-09-28  9:05       ` Stefan Hajnoczi
2020-09-28 10:33         ` Kevin Wolf
2020-09-09 15:24 ` [PATCH v7 00/13] monitor: Optionally run handlers in coroutines no-reply
2020-09-10 13:24 ` Stefan Hajnoczi
2020-09-14 15:09   ` Markus Armbruster
2020-09-15 14:58     ` Stefan Hajnoczi
2020-09-25 17:15   ` Kevin Wolf
2020-09-28  8:46     ` Stefan Hajnoczi
2020-09-28  9:47       ` Kevin Wolf
2020-09-28  9:30     ` 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=20200925153707.GG5731@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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.