From: Peter Xu <peterx@redhat.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: "Fabiano Rosas" <farosas@suse.de>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Avihai Horon" <avihaih@nvidia.com>,
"Joao Martins" <joao.m.martins@oracle.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers
Date: Tue, 29 Oct 2024 17:04:02 -0400 [thread overview]
Message-ID: <ZyFNwtFuBrZjRhm1@x1n> (raw)
In-Reply-To: <4836f787-5e39-441a-b8b1-a2238bdf228e@maciej.szmigiero.name>
On Tue, Oct 29, 2024 at 09:46:01PM +0100, Maciej S. Szmigiero wrote:
> On 29.10.2024 21:35, Peter Xu wrote:
> > On Tue, Oct 29, 2024 at 03:58:16PM +0100, Maciej S. Szmigiero wrote:
> > > From: "Maciej S. Szmigiero" <maciej.szmigiero@oracle.com>
> > >
> > > Some of these SaveVMHandlers were missing the BQL behavior annotation,
> > > making people wonder what it exactly is.
> > >
> > > Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
> > > ---
> > > include/migration/register.h | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/include/migration/register.h b/include/migration/register.h
> > > index f60e797894e5..c411d84876ec 100644
> > > --- a/include/migration/register.h
> > > +++ b/include/migration/register.h
> > > @@ -210,6 +210,8 @@ typedef struct SaveVMHandlers {
> > > void (*state_pending_exact)(void *opaque, uint64_t *must_precopy,
> > > uint64_t *can_postcopy);
> > > + /* This runs inside the BQL. */
> > > +
> > > /**
> > > * @load_state
> > > *
> > > @@ -227,6 +229,8 @@ typedef struct SaveVMHandlers {
> > > */
> > > int (*load_state)(QEMUFile *f, void *opaque, int version_id);
> > > + /* The following handlers run inside the BQL. */
> >
> > If above also requires BQL, why not move this line upper?
>
> The reason for this is that my main patch set also adds
> "load_state_buffer" handler, which runs without BQL.
>
> That handler is ordered next after "load_state" and I tried
> to avoid further comment churn here.
>
> But if you prefer to change these comments in the patch
> introducing "load_state_buffer" handler instead then it's
> fine.
Considering the current change is so small to start benefit readers.. I
think it's ok we do this in one shot after load_state_buffer() change.
> > OTOH, I think resume_prepare() doesn't require BQL..
>
> Yes, it seems like resume_prepare() is only called outside BQL.
> Will update the patch.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-10-29 21:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 14:58 [PATCH 0/4] Trivial patches from multifd device state transfer support patch set Maciej S. Szmigiero
2024-10-29 14:58 ` [PATCH 1/4] vfio/migration: Add save_{iterate, complete_precopy}_started trace events Maciej S. Szmigiero
2024-10-31 14:21 ` [PATCH 1/4] vfio/migration: Add save_{iterate,complete_precopy}_started " Avihai Horon
2024-10-31 22:17 ` Maciej S. Szmigiero
2024-11-01 16:48 ` Maciej S. Szmigiero
2024-11-04 8:08 ` Avihai Horon
2024-11-04 14:00 ` Maciej S. Szmigiero
2024-11-04 14:10 ` Avihai Horon
2024-10-29 14:58 ` [PATCH 2/4] migration/ram: Add load start trace event Maciej S. Szmigiero
2024-10-29 19:10 ` Fabiano Rosas
2024-10-29 14:58 ` [PATCH 3/4] migration/multifd: Zero p->flags before starting filling a packet Maciej S. Szmigiero
2024-10-29 14:58 ` [PATCH 4/4] migration: Document the BQL behavior of load SaveVMHandlers Maciej S. Szmigiero
2024-10-29 19:26 ` Fabiano Rosas
2024-10-29 20:35 ` Peter Xu
2024-10-29 20:46 ` Maciej S. Szmigiero
2024-10-29 21:04 ` Peter Xu [this message]
2024-10-29 20:40 ` [PATCH 0/4] Trivial patches from multifd device state transfer support patch set Peter Xu
2024-10-29 20:46 ` Maciej S. Szmigiero
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=ZyFNwtFuBrZjRhm1@x1n \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=joao.m.martins@oracle.com \
--cc=mail@maciej.szmigiero.name \
--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 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).