All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: "Fabiano Rosas" <farosas@suse.de>,
	"Alex Williamson" <alex@shazbot.org>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Avihai Horon" <avihaih@nvidia.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH 2/2] vfio/migration: Parallelize device state transitions
Date: Mon, 20 Jul 2026 10:55:58 -0400	[thread overview]
Message-ID: <al42_qzCLAjE-Mch@x1.local> (raw)
In-Reply-To: <cb1bdf37-58e8-4498-bc56-d65c4fcc3fa0@maciej.szmigiero.name>

On Fri, Jul 17, 2026 at 04:31:32PM +0200, Maciej S. Szmigiero wrote:
> Inside the VFIO code such sync point for VFIO devices could/should indeed
> be created, but then it's not available for these other (non-VFIO) devices
> for the purpose of avoiding the regression from the previous paragraph.
> 
> However, replacing the order priority/adjustment mechanism from patch 1
> with the "pre" and "post" handlers I described above would avoid having
> that regression (and help fix the vhost-net case too).

I'm not sure I fully get the pre/post handlers idea, I think it sounds
working, but in all cases I want to decouple it with patch 1: I don't think
it requires patch 1, am I right?

Now if we want to avoid this "theoretical regression" and solve both things
together.. I think we may need to refactor the notifiers mechanism.

Firstly, I hope we're on the same page that essentially prepare_cb() is the
priority mechanism here, we only have HIGH and NORMAL priority, where cb()
is the NORMAL priority.

We also need to persist depth concept per-notifier, I think we should start
by renaming VMChangeStateEntry.priority to depth, add a comment explaining
it (on different order of invokations on VM start/shutdown).

But then, I don't think we need anything as complex as pre/post hooks with
hashes.  I think you're right then we need SYNC point which can be
essentially a priority notifier that is in the middle of HIGH and NORMAL.

Hence, I want to see if below should be the easiest:

  - Rename VMChangeStateEntry.priority to depth

  - Normalize prepare_cb() into VM_CHANGE_NOTIFY_PRI_HIGH, making cb() to
    be NORMAL, OTOH.  With this, prepare_cb() needs to be registered
    separately with qemu_add_vm_change_state_handler_prio_full().  The
    function now should drop prepare_cb() but instead take a real
    "priority" value of VM_CHANGE_NOTIFY_PRI_*.

  - Introduce VM_CHANGE_NOTIFY_PRI_SYNC, in the middle of PREPARE / NORMAL.

  - VFIO can now register its 3rd notifier against SYNC.

All rest devices will need to shift part of its logic into PRI_HIGH to
either quiesce DMA or enable the backend to accept DMA (when on dest QEMU).
None of them will need SYNC only if they'll also switch to an async thread
model.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2026-07-20 14:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 14:41 [PATCH 0/2] VFIO device migration parallel state transitions Maciej S. Szmigiero
2026-05-20 14:41 ` [PATCH 1/2] system/runstate: Allow adjustment of priority for VM state change handlers Maciej S. Szmigiero
2026-06-01 13:26   ` Fabiano Rosas
2026-05-20 14:41 ` [PATCH 2/2] vfio/migration: Parallelize device state transitions Maciej S. Szmigiero
2026-06-01 13:39   ` Fabiano Rosas
2026-06-01 19:33     ` Peter Xu
2026-06-02 10:01       ` Maciej S. Szmigiero
2026-06-02 20:17         ` Peter Xu
2026-06-03 21:34           ` Maciej S. Szmigiero
2026-07-02 18:36             ` Maciej S. Szmigiero
2026-07-06 16:23               ` Peter Xu
2026-07-13 20:23                 ` Maciej S. Szmigiero
2026-07-14 17:06                   ` Peter Xu
2026-07-14 20:23                     ` Maciej S. Szmigiero
2026-07-15 15:30                       ` Peter Xu
2026-07-16 12:18                         ` Maciej S. Szmigiero
2026-07-16 13:30                           ` Peter Xu
2026-07-17 14:31                             ` Maciej S. Szmigiero
2026-07-20 14:55                               ` Peter Xu [this message]
2026-07-21 15:07                                 ` Maciej S. Szmigiero
2026-07-21 18:21                                   ` Peter Xu

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=al42_qzCLAjE-Mch@x1.local \
    --to=peterx@redhat.com \
    --cc=alex@shazbot.org \
    --cc=avihaih@nvidia.com \
    --cc=clg@redhat.com \
    --cc=farosas@suse.de \
    --cc=mail@maciej.szmigiero.name \
    --cc=pbonzini@redhat.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.