From: Peter Xu <peterx@redhat.com>
To: Avihai Horon <avihaih@nvidia.com>
Cc: "Cédric Le Goater" <clg@redhat.com>,
qemu-devel@nongnu.org, "Alex Williamson" <alex@shazbot.org>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>
Subject: Re: [PATCH] vfio/migration: Send migration event before device state transition
Date: Wed, 28 Jan 2026 12:38:47 -0500 [thread overview]
Message-ID: <aXpJpwLvHTAXfpon@x1.local> (raw)
In-Reply-To: <591f4e36-11a8-4310-a74a-6166698d7b23@nvidia.com>
On Wed, Jan 28, 2026 at 07:13:43PM +0200, Avihai Horon wrote:
> In our case we only use the PRE_COPY_P2P prepare event. The prepare events
> for the other states are ignored.
> For re-enabling the timeout mechanism we indeed use the "regular" (not
> prepare) events.
>
> However, this new event can be used by anyone for any purpose, so I didn't
> want to limit it only for my use case.
I see your point.
Said that, in this specific case, my worry is nobody will consume the rest
events, and then after a few years nobody can even tell why it ever
existed. Then QEMU needs to emits some never-used events forever, worrying
about breaking anyone, even if in reality they're always ignored.
Personally I think it makes more sense to add one explicit message as you
explicitly need. Then, that message can be as generic as possible on its
own. But I'll leave that to you and VFIO maintainers to decide.
>
> >
> > I do not know VFIO state machine well, also not familiar with this specific
> > problem. So please treat them as pure questions. Anyway, it'll be always
> > nice to attach some more information into the commit log IMHO.
>
> Sure.
> As I said earlier, I didn't want to tie this new event to my specific use
> case, but rather wanted to describe the general problem it can solve.
> But if that helps, I can add some more details in the commit message in next
> version.
That'll always be very helpful, thank you!
--
Peter Xu
next prev parent reply other threads:[~2026-01-28 17:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 10:51 [PATCH] vfio/migration: Send migration event before device state transition Avihai Horon
2026-01-28 11:03 ` Cédric Le Goater
2026-01-28 14:49 ` Peter Xu
2026-01-28 15:32 ` Avihai Horon
2026-01-28 16:21 ` Peter Xu
2026-01-28 17:13 ` Avihai Horon
2026-01-28 17:38 ` Peter Xu [this message]
2026-01-29 5:11 ` Avihai Horon
2026-01-29 14:31 ` Cédric Le Goater
2026-01-29 21:18 ` Avihai Horon
2026-01-30 13:34 ` Cédric Le Goater
2026-02-04 13:03 ` Markus Armbruster
2026-02-04 13:12 ` Avihai Horon
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=aXpJpwLvHTAXfpon@x1.local \
--to=peterx@redhat.com \
--cc=alex@shazbot.org \
--cc=armbru@redhat.com \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--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.