Hi Peter, Noted, on documenting the external discussions and including them in future cover letters and commit messages.
REgarding the guest psize > host psize code cleanup, I'd be happy to send a small follow-up on top of current patches reverting the checks and simplifying the pending_bmap logic Thank you, really excited to see the series queued for 11.2. I can't thank you enough for your guidance, patience, and mentorship throughout the summer. On Tue, Aug 18, 2026 at 11:15 PM Peter Xu <[email protected]> wrote: > > Hey, Aadeshveer, > > On Sun, Aug 16, 2026 at 11:16:20PM +0530, Aadeshveer Singh wrote: > > v4 -> v5 > > - Modify pending_bmap(Patch 6) to use variable size for better > > efficient atomic state management > > - Added a comment(Patch 7) explaining postcopy_mapped_ram_load_page > > explaining why cases where guest page is larger than host page are > > disabled following what remote postcopy follows > > - Add a new check(Patch 9) in migrate_prepare to bail out if migrate > > was used with fast snapshot load enabled, as suggested by Peter > > There're something you didn't mention but we discussed it only during the > meeting about host/guest psize problem. For this time, I'll do it for you. > Aadeshveer, please remember to mention such conclusions and findings in the > future when you will be working on other patches. > > The quick summary: Aadeshveer found postcopy doesn't support guest psize > > host psize since the start, which will already fail the set capabilities in > postcopy_ram_supported_by_host(). It means we can also skip supporting > that in fast snapshot load. > > Personally, I still prefer removal of all such guest psize > host psize > handlings in your current code; postcopy_place_page() isn't ready, so the > current code won't work anyway for that setup. With it removed, then we > can stick pending_bmap with host psize, which can also cause less confusion > and make it easier to read. But I think it's not a huge deal, and AFAIU > the code works as expected. So I think it's fine for now. > > If you're going to prepare a small series on top of this, please consider > reverting those changes back to the simple version with one patch on top. > > Other than that, thanks for your hard work in the past few months! Since I > believe this code still should function all well, I queued it for 11.2. > > -- > Peter Xu >
