On Wed, Jul 08, 2026 at 08:01:34PM +0530, Aadeshveer Singh wrote:
> > > +static bool postcopy_mapped_ram_load_page(MigrationIncomingState *mis,
> > > + RAMBlock *rb, ram_addr_t
> > > rb_offset,
> > > + uint64_t haddr, int channel,
> > > + Error **errp)
> > > +{
> > > + void *place_source = mis->postcopy_tmp_pages[channel].tmp_huge_page;
> > > + size_t page;
> > > + size_t read;
> > > +
> > > + page = rb_offset / qemu_ram_pagesize(rb);
> >
> > Yes, here it is correct to use qemu_ram_pagesize().
> >
> > > +
> > > + if (bitmap_test_and_clear_atomic(rb->pending_bmap, page, 1)) {
> > > + if (test_bit(page, rb->file_bmap)) {
> >
> > We'll need to be careful here when you add huge page support, because
> > file_bmap so far is guest-psize based. This line will start to break for
> > huge pages, I am not sure if this is the bug you hit when developing huge
> > page support, maybe yes?
> >
> > Not sure how you resolved it there if this is the case, but one idea is
> > when postcopy-ram is enabled, you can convert the per-guest-psize bitmap
> > into per-host-psize bitmap (when any bit set within the huge page range,
> > set the bit in the new bitmap), then here it will be correct.
> >
>
> For hugepages, I replaced this test_bit() with a ranged check. I felt
> changing the semantics of file_bmap for when postcopy-ram is enabled
When support huge pages, in previous patch if you will already switch to
using ramblock page size for pending_bmap then I think we should indeed be
good here.
With that, actually file_bmap to be guest-psize is definitely
better.. please ignore my above suggestion on bitmap conversions. We just
need to loop over all the bits of the huge page, when the bit is clear,
instead of UFFDIO_ZEROPAGE, we should just do memset(0) for 4k (the tmp
page may have been non-zero prefilled).
I'll wait to see the new version when huge page support is there.
Thanks,
--
Peter Xu
