qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	Auger Eric <eric.auger@redhat.com>,
	teawater <teawaterz@linux.alibaba.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Marek Kedzierski <mkedzier@redhat.com>
Subject: Re: [PATCH v1 1/9] memory: Introduce RamDiscardMgr for RAM memory regions
Date: Wed, 2 Dec 2020 16:26:15 -0700	[thread overview]
Message-ID: <20201202162615.523a6a75@w520.home> (raw)
In-Reply-To: <20201119153918.120976-2-david@redhat.com>

On Thu, 19 Nov 2020 16:39:10 +0100
David Hildenbrand <david@redhat.com> wrote:

> We have some special RAM memory regions (managed by virtio-mem), whereby
> the guest agreed to only use selected memory ranges. "unused" parts are
> discarded so they won't consume memory - to logically unplug these memory
> ranges. Before the VM is allowed to use such logically unplugged memory
> again, coordination with the hypervisor is required.
> 
> This results in "sparse" mmaps/RAMBlocks/memory regions, whereby only
> coordinated parts are valid to be used/accessed by the VM.
> 
> In most cases, we don't care about that - e.g., in KVM, we simply have a
> single KVM memory slot. However, in case of vfio, registering the
> whole region with the kernel results in all pages getting pinned, and
> therefore an unexpected high memory consumption - discarding of RAM in
> that context is broken.
> 
> Let's introduce a way to coordinate discarding/populating memory within a
> RAM memory region with such special consumers of RAM memory regions: they
> can register as listeners and get updates on memory getting discarded and
> populated. Using this machinery, vfio will be able to map only the
> currently populated parts, resulting in discarded parts not getting pinned
> and not consuming memory.
> 
> A RamDiscardMgr has to be set for a memory region before it is getting
> mapped, and cannot change while the memory region is mapped.
> 
> Note: At some point, we might want to let RAMBlock users (esp. vfio used
> for nvme://) consume this interface as well. We'll need RAMBlock notifier
> calls when a RAMBlock is getting mapped/unmapped (via the corresponding
> memory region), so we can properly register a listener there as well.
> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Auger Eric <eric.auger@redhat.com>
> Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
> Cc: teawater <teawaterz@linux.alibaba.com>
> Cc: Marek Kedzierski <mkedzier@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  include/exec/memory.h | 225 ++++++++++++++++++++++++++++++++++++++++++
>  softmmu/memory.c      |  22 +++++
>  2 files changed, 247 insertions(+)
> 
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index 0f3e6bcd5e..468cbb53a4 100644
> --- a/include/exec/memory.h
> +++ b/include/exec/memory.h
...
> @@ -425,6 +501,120 @@ struct IOMMUMemoryRegionClass {
>                                       Error **errp);
>  };
>  
> +/*
> + * RamDiscardMgrClass:
> + *
> + * A #RamDiscardMgr coordinates which parts of specific RAM #MemoryRegion
> + * regions are currently populated to be used/accessed by the VM, notifying
> + * after parts were discarded (freeing up memory) and before parts will be
> + * populated (consuming memory), to be used/acessed by the VM.
> + *
> + * A #RamDiscardMgr can only be set for a RAM #MemoryRegion while the
> + * #MemoryRegion isn't mapped yet; it cannot change while the #MemoryRegion is
> + * mapped.
> + *
> + * The #RamDiscardMgr is intended to be used by technologies that are
> + * incompatible with discarding of RAM (e.g., VFIO, which may pin all
> + * memory inside a #MemoryRegion), and require proper coordination to only
> + * map the currently populated parts, to hinder parts that are expected to
> + * remain discarded from silently getting populated and consuming memory.
> + * Technologies that support discarding of RAM don't have to bother and can
> + * simply map the whole #MemoryRegion.
> + *
> + * An example #RamDiscardMgr is virtio-mem, which logically (un)plugs
> + * memory within an assigned RAM #MemoryRegion, coordinated with the VM.
> + * Logically unplugging memory consists of discarding RAM. The VM agreed to not
> + * access unplugged (discarded) memory - especially via DMA. virtio-mem will
> + * properly coordinate with listeners before memory is plugged (populated),
> + * and after memory is unplugged (discarded).
> + *
> + * Listeners are called in multiples of the minimum granularity and changes are
> + * aligned to the minimum granularity within the #MemoryRegion. Listeners have
> + * to prepare for memory becomming discarded in a different granularity than it
> + * was populated and the other way around.
> + */
> +struct RamDiscardMgrClass {
> +    /* private */
> +    InterfaceClass parent_class;
> +
> +    /* public */
> +
> +    /**
> +     * @get_min_granularity:
> +     *
> +     * Get the minimum granularity in which listeners will get notified
> +     * about changes within the #MemoryRegion via the #RamDiscardMgr.
> +     *
> +     * @rdm: the #RamDiscardMgr
> +     * @mr: the #MemoryRegion
> +     *
> +     * Returns the minimum granularity.
> +     */
> +    uint64_t (*get_min_granularity)(const RamDiscardMgr *rdm,
> +                                    const MemoryRegion *mr);
> +
> +    /**
> +     * @is_populated:
> +     *
> +     * Check whether the given range within the #MemoryRegion is completely
> +     * populated (i.e., no parts are currently discarded). There are no
> +     * alignment requirements for the range.
> +     *
> +     * @rdm: the #RamDiscardMgr
> +     * @mr: the #MemoryRegion
> +     * @offset: offset into the #MemoryRegion
> +     * @size: size in the #MemoryRegion
> +     *
> +     * Returns the minimum granularity.


I think the return description got copied from above, this returns bool.

...
> diff --git a/softmmu/memory.c b/softmmu/memory.c
> index aa393f1bb0..fbdc50fa8b 100644
> --- a/softmmu/memory.c
> +++ b/softmmu/memory.c
> @@ -2013,6 +2013,21 @@ int memory_region_iommu_num_indexes(IOMMUMemoryRegion *iommu_mr)
>      return imrc->num_indexes(iommu_mr);
>  }
>  
> +RamDiscardMgr *memory_region_get_ram_discard_mgr(MemoryRegion *mr)
> +{
> +    if (!memory_region_is_mapped(mr) || !memory_region_is_ram(mr)) {
> +        return false;

s/false/NULL/?

> +    }
> +    return mr->rdm;
> +}
> +



  reply	other threads:[~2020-12-02 23:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-19 15:39 [PATCH v1 0/9] virtio-mem: vfio support David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 1/9] memory: Introduce RamDiscardMgr for RAM memory regions David Hildenbrand
2020-12-02 23:26   ` Alex Williamson [this message]
2020-12-03 10:04     ` David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 2/9] virtio-mem: Factor out traversing unplugged ranges David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 3/9] virtio-mem: Implement RamDiscardMgr interface David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 4/9] vfio: Support for RamDiscardMgr in the !vIOMMU case David Hildenbrand
2020-12-02 23:26   ` Alex Williamson
2020-12-03 10:07     ` David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 5/9] vfio: Support for RamDiscardMgr in the vIOMMU case David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 6/9] softmmu/physmem: Don't use atomic operations in ram_block_discard_(disable|require) David Hildenbrand
2020-11-19 20:34   ` Peter Xu
2020-11-19 15:39 ` [PATCH v1 7/9] softmmu/physmem: Extend ram_block_discard_(require|disable) by two discard types David Hildenbrand
2020-11-19 15:39 ` [PATCH v1 8/9] virtio-mem: Require only coordinated discards David Hildenbrand
2020-11-30 17:20   ` Dr. David Alan Gilbert
2020-11-19 15:39 ` [PATCH v1 9/9] vfio: Disable only uncoordinated discards David Hildenbrand
2020-11-23 11:31 ` [PATCH v1 0/9] virtio-mem: vfio support David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201202162615.523a6a75@w520.home \
    --to=alex.williamson@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mkedzier@redhat.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.weiyang@linux.alibaba.com \
    --cc=teawaterz@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).