Re: [PATCH v2 05/16] migration/treewide: Merge @state_pending_{exact|estimate} APIs

[Peter Xu <peterx@redhat.com>]

On Wed, Apr 22, 2026 at 11:29:11AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 21.04.26 23:20, Peter Xu wrote:
> > These two APIs are a slight duplication.  For example, there're a few users
> > that directly pass in the same function.
> > 
> > It might also be error prone to provide two hooks, so that it's easier to
> > happen one module report different things via the two hooks.
> > 
> > In reality, they should always report the same thing, only about whether we
> > should use a fast-path when the slow path might be too slow, as QEMU may
> > query these information quite frequently during migration process.
> > 
> > Merge it into one API, provide a bool showing if the query is an exact
> > query or not.  No functional change intended.
> > 
> > Export qemu_savevm_query_pending().  We should use the new API here
> > provided when there're new users to do the query.  This will happen very
> > soon.
> > 
> > Cc: Halil Pasic<pasic@linux.ibm.com>
> > Cc: Christian Borntraeger<borntraeger@linux.ibm.com>
> > Cc: Eric Farman<farman@linux.ibm.com>
> > Cc: Matthew Rosato<mjrosato@linux.ibm.com>
> > Cc: Richard Henderson<richard.henderson@linaro.org>
> > Cc: Ilya Leoshkevich<iii@linux.ibm.com>
> > Cc: David Hildenbrand<david@kernel.org>
> > Cc: Cornelia Huck<cohuck@redhat.com>
> > Cc: Eric Blake<eblake@redhat.com>
> > Cc: Vladimir Sementsov-Ogievskiy<vsementsov@yandex-team.ru>
> > Cc: John Snow<jsnow@redhat.com>
> > Reviewed-by: Jason J. Herne<jjherne@linux.ibm.com>
> > Reviewed-by: Juraj Marcin<jmarcin@redhat.com>
> > Reviewed-by: Avihai Horon<avihaih@nvidia.com>
> > Signed-off-by: Peter Xu<peterx@redhat.com>
> 
> 
> Probably too late after all these r-b-s, but it would be simpler to review,
> if renaming and reworking the documentation of the fields, moving them
> to a separate structure, and combining two handler functions into one
> would all be different patches.

Split of the patch might involve some code added then quickly removed
again, which I also want to avoid.

Considering the reviews done on this series (and the challenge of finding
hardwares to test..), I'd appreciate if you're OK we land this sooner then
rework whatever thing on top if the changes will be cosmetic.  That is, I
agree your question with the documentation for using "can" in the new API:
it is a bit ambiguous indeed.  I'll see how I will integrate them best, it
may depend on whether there're other reasons for a full repost / retest.

Thanks,

-- 
Peter Xu