On Thu, 7 Jan 2021 14:34:23 +0100
David Hildenbrand <da...@redhat.com> wrote:
> We support coordinated discarding of RAM using the RamDiscardMgr. Let's
> unlock support for coordinated discards, keeping uncoordinated discards
> (e.g., via virtio-balloon) disabled.
>
> This unlocks virtio-mem + vfio. Note that vfio used via "nvme://" by the
> block layer has to be implemented/unlocked separately. For now,
> virtio-mem only supports x86-64 - spapr IOMMUs are not tested/affected.
I think SPAPR always uses a vIOMMU, but I won't claim to understand it.
Is there anything other than testing that restricts it to x86-64? ARM
and S390 will use the same type1 IOMMU backend as far as vfio support
is concerned. Should we do something more than put it in a commit log
if we really want to prevent it elsewhere? Thanks,
Alex
> Note: The block size of a virtio-mem device has to be set to sane sizes,
> depending on the maximum hotplug size - to not run out of vfio mappings.
> The default virtio-mem block size is usually in the range of a couple of
> MBs. The maximum number of mapping is 64k, shared with other users.
> Assume you want to hotplug 256GB using virtio-mem - the block size would
> have to be set to at least 8 MiB (resulting in 32768 separate mappings).
>
> Reviewed-by: Pankaj Gupta <pankaj.gu...@cloud.ionos.com>
> Cc: Paolo Bonzini <pbonz...@redhat.com>
> Cc: "Michael S. Tsirkin" <m...@redhat.com>
> Cc: Alex Williamson <alex.william...@redhat.com>
> Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Cc: Igor Mammedov <imamm...@redhat.com>
> Cc: Pankaj Gupta <pankaj.gupta.li...@gmail.com>
> Cc: Peter Xu <pet...@redhat.com>
> Cc: Auger Eric <eric.au...@redhat.com>
> Cc: Wei Yang <richard.weiy...@linux.alibaba.com>
> Cc: teawater <teawat...@linux.alibaba.com>
> Cc: Marek Kedzierski <mkedz...@redhat.com>
> Signed-off-by: David Hildenbrand <da...@redhat.com>
> ---
> hw/vfio/common.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 2b9ba3f8c9..ee7a82524a 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -1976,8 +1976,10 @@ static int vfio_connect_container(VFIOGroup *group,
> AddressSpace *as,
> * new memory, it will not yet set ram_block_discard_set_required() and
> * therefore, neither stops us here or deals with the sudden memory
> * consumption of inflated memory.
> + *
> + * We do support discarding of memory coordinated via the RamDiscardMgr.
> */
> - ret = ram_block_discard_disable(true);
> + ret = ram_block_uncoordinated_discard_disable(true);
> if (ret) {
> error_setg_errno(errp, -ret, "Cannot set discarding of RAM broken");
> return ret;
> @@ -2157,7 +2159,7 @@ close_fd_exit:
> close(fd);
>
> put_space_exit:
> - ram_block_discard_disable(false);
> + ram_block_uncoordinated_discard_disable(false);
> vfio_put_address_space(space);
>
> return ret;
> @@ -2279,7 +2281,7 @@ void vfio_put_group(VFIOGroup *group)
> }
>
> if (!group->ram_block_discard_allowed) {
> - ram_block_discard_disable(false);
> + ram_block_uncoordinated_discard_disable(false);
> }
> vfio_kvm_device_del_group(group);
> vfio_disconnect_container(group);
> @@ -2333,7 +2335,7 @@ int vfio_get_device(VFIOGroup *group, const char *name,
>
> if (!group->ram_block_discard_allowed) {
> group->ram_block_discard_allowed = true;
> - ram_block_discard_disable(false);
> + ram_block_uncoordinated_discard_disable(false);
> }
> }
>
