From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com, quintela@redhat.com,
peterx@redhat.com, leobras@redhat.com, pbonzini@redhat.com,
qemu-block@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [PATCH 0/2] virtio: Drop out of coroutine context in virtio_load()
Date: Fri, 8 Sep 2023 10:53:00 +0200 [thread overview]
Message-ID: <ZPrg7L2lpggb9enZ@redhat.com> (raw)
In-Reply-To: <20230907184200.GB1560640@fedora>
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
Am 07.09.2023 um 20:42 hat Stefan Hajnoczi geschrieben:
> On Tue, Sep 05, 2023 at 04:50:00PM +0200, Kevin Wolf wrote:
> > This fixes a recently introduced assertion failure that was reported to
> > happen when migrating virtio-net with a failover. The latent bug that
> > we're executing code in coroutine context that was never supposed to run
> > there has existed for a long time. However, the new assertion that
> > callers of bdrv_graph_rdlock_main_loop() don't run in coroutine context
> > makes it very visible because it's now always a crash.
> >
> > Kevin Wolf (2):
> > vmstate: Mark VMStateInfo.get/put() coroutine_mixed_fn
> > virtio: Drop out of coroutine context in virtio_load()
> >
> > include/migration/vmstate.h | 8 ++++---
> > hw/virtio/virtio.c | 45 ++++++++++++++++++++++++++++++++-----
> > 2 files changed, 45 insertions(+), 8 deletions(-)
>
> This looks like a bandaid for a specific instance of this problem
> rather than a solution that takes care of the root cause.
>
> Is it possible to make VMStateInfo.get/put() consistenty coroutine_fn?
I think it is. Note that this doesn't solve the problem, virtio_load()
calls functions that must run _outside_ coroutine context. So once the
migration code is cleaned up to consistenly run in coroutine context,
you can remove the check and the one line for the !qemu_in_coroutine()
case from this series. The rest stays as it is.
It is not a solution that takes care of the root cause, but I also can't
think of one. The problem is that VMState callbacks both read/write the
migration stream (which should be done in coroutine context) and set the
device state (which can involve functions that must not run in coroutine
context). Untangling this, if possible at all, is not easy and certainly
not something for stable releases.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-09-08 8:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 14:50 [PATCH 0/2] virtio: Drop out of coroutine context in virtio_load() Kevin Wolf
2023-09-05 14:50 ` [PATCH 1/2] vmstate: Mark VMStateInfo.get/put() coroutine_mixed_fn Kevin Wolf
2023-09-05 15:06 ` Peter Xu
2023-09-05 14:50 ` [PATCH 2/2] virtio: Drop out of coroutine context in virtio_load() Kevin Wolf
2023-09-07 18:40 ` Stefan Hajnoczi
2023-09-08 8:59 ` Kevin Wolf
2023-09-08 10:46 ` Stefan Hajnoczi
2023-10-17 5:19 ` Michael Tokarev
2023-10-17 8:48 ` Kevin Wolf
2023-10-17 13:06 ` Juan Quintela
2023-09-07 18:42 ` [PATCH 0/2] " Stefan Hajnoczi
2023-09-08 8:53 ` Kevin Wolf [this message]
2023-09-08 10:46 ` Stefan Hajnoczi
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=ZPrg7L2lpggb9enZ@redhat.com \
--to=kwolf@redhat.com \
--cc=leobras@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=quintela@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).