Re: [Qemu-devel] [PATCH v2 1/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Wei Wang (wei.w.wang@intel.com) wrote:

<snip>

> @@ -374,6 +459,7 @@ static uint64_t virtio_balloon_get_features(VirtIODevice *vdev, uint64_t f,
>      VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
>      f |= dev->host_features;
>      virtio_add_feature(&f, VIRTIO_BALLOON_F_STATS_VQ);
> +    virtio_add_feature(&f, VIRTIO_BALLOON_F_PAGE_POISON);

I agree with Michael that has to be tied to a compatibility flag
somewhere; otherwise we'd hit problems with migration to older QEMUs of
newer guests.

> diff --git a/migration/ram.c b/migration/ram.c
> index cb1950f..d6f462c 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2186,6 +2186,16 @@ static int ram_init_all(RAMState **rsp)
>      return 0;
>  }
>  
> +void skip_free_pages_from_dirty_bitmap(RAMBlock *block, ram_addr_t offset,
> +                                       size_t len)
> +{
> +    long start = offset >> TARGET_PAGE_BITS,
> +         nr = len >> TARGET_PAGE_BITS;
> +
> +    bitmap_clear(block->bmap, start, nr);
> +    ram_state->migration_dirty_pages -= nr;
> +}
> +

I don't think this will work for postcopy; just not sending a page will
mean that the guest will block in userfault waiting for the page
(then it will request it but it wont be sent because the source already
thinks it's clean).

I think you're going to need to make the 'unused' pages be sent as zero
pages; probably by modifying save_zero_page to check a bitmap.

(I'm not sure how that will interact with hugepages)

Dave

>  /*
>   * Each of ram_save_setup, ram_save_iterate and ram_save_complete has
>   * long-running RCU critical section.  When rcu-reclaims in the code
> -- 
> 1.8.3.1
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK