Re: [PATCH RFC 21/21] migration: Collapse huge pages again after postcopy finished

[Juan Quintela]

Peter Xu <peterx@redhat.com> wrote:
> When hugetlb-doublemap enabled, the pages will be migrated in small page
> sizes during postcopy.  When the migration finishes, the pgtable needs to
> be rebuilt explicitly for these ranges to have huge page being mapped again.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  migration/ram.c        | 31 +++++++++++++++++++++++++++++++
>  migration/trace-events |  1 +
>  2 files changed, 32 insertions(+)
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 4da56d925c..178739f8c3 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3986,6 +3986,31 @@ static int ram_load_setup(QEMUFile *f, void *opaque)
>      return 0;
>  }
>  
> +#define  MADV_COLLAPSE_CHUNK_SIZE  (1UL << 30) /* 1G */
> +
> +static void ramblock_rebuild_huge_mappings(RAMBlock *rb)
> +{
> +    unsigned long addr, size;

This makes my head explode.

We have:

unsigned long
__u64
uint64_t

Used and mixed all around.

> +    assert(qemu_ram_is_hugetlb(rb));
> +
> +    addr = (unsigned long)qemu_ram_get_host_addr(rb);

Don't this cast should be uintptr_t?
At least on win64 it should fail, no?

> +    size = rb->mmap_length;

this is ram_addr_t.  It is uint64_t except with xen.
So it should fail on any 32 bit host.

Later, Juan.