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<[email protected]> > > Cc: Christian Borntraeger<[email protected]> > > Cc: Eric Farman<[email protected]> > > Cc: Matthew Rosato<[email protected]> > > Cc: Richard Henderson<[email protected]> > > Cc: Ilya Leoshkevich<[email protected]> > > Cc: David Hildenbrand<[email protected]> > > Cc: Cornelia Huck<[email protected]> > > Cc: Eric Blake<[email protected]> > > Cc: Vladimir Sementsov-Ogievskiy<[email protected]> > > Cc: John Snow<[email protected]> > > Reviewed-by: Jason J. Herne<[email protected]> > > Reviewed-by: Juraj Marcin<[email protected]> > > Reviewed-by: Avihai Horon<[email protected]> > > Signed-off-by: Peter Xu<[email protected]> > > > 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
