All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	Wei Yang <richard.weiyang@linux.alibaba.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	Pankaj Gupta <pankaj.gupta@cloud.ionos.com>,
	Auger Eric <eric.auger@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	teawater <teawaterz@linux.alibaba.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Marek Kedzierski <mkedzier@redhat.com>
Subject: Re: [PATCH v7 00/13] virtio-mem: vfio support
Date: Tue, 2 Mar 2021 17:46:56 +0100	[thread overview]
Message-ID: <4c44dd6b-0490-8b70-490a-e456e8e96039@redhat.com> (raw)
In-Reply-To: <20210224094910.44986-1-david@redhat.com>

On 24.02.21 10:48, David Hildenbrand wrote:
> A virtio-mem device manages a memory region in guest physical address
> space, represented as a single (currently large) memory region in QEMU,
> mapped into system memory address space. Before the guest is allowed to use
> memory blocks, it must coordinate with the hypervisor (plug blocks). After
> a reboot, all memory is usually unplugged - when the guest comes up, it
> detects the virtio-mem device and selects memory blocks to plug (based on
> resize requests from the hypervisor).
> 
> Memory hot(un)plug consists of (un)plugging memory blocks via a virtio-mem
> device (triggered by the guest). When unplugging blocks, we discard the
> memory - similar to memory balloon inflation. In contrast to memory
> ballooning, we always know which memory blocks a guest may actually use -
> especially during a reboot, after a crash, or after kexec (and during
> hibernation as well). Guests agreed to not access unplugged memory again,
> especially not via DMA.
> 
> The issue with vfio is, that it cannot deal with random discards - for this
> reason, virtio-mem and vfio can currently only run mutually exclusive.
> Especially, vfio would currently map the whole memory region (with possible
> only little/no plugged blocks), resulting in all pages getting pinned and
> therefore resulting in a higher memory consumption than expected (turning
> virtio-mem basically useless in these environments).
> 
> To make vfio work nicely with virtio-mem, we have to map only the plugged
> blocks, and map/unmap properly when plugging/unplugging blocks (including
> discarding of RAM when unplugging). We achieve that by using a new notifier
> mechanism that communicates changes.
> 
> It's important to map memory in the granularity in which we could see
> unmaps again (-> virtio-mem block size) - so when e.g., plugging
> consecutive 100 MB with a block size of 2 MB, we need 50 mappings. When
> unmapping, we can use a single vfio_unmap call for the applicable range.
> We expect that the block size of virtio-mem devices will be fairly large
> in the future (to not run out of mappings and to improve hot(un)plug
> performance), configured by the user, when used with vfio (e.g., 128MB,
> 1G, ...), but it will depend on the setup.
> 
> More info regarding virtio-mem can be found at:
>      https://virtio-mem.gitlab.io/
> 
> v7 is located at:
>    git@github.com:davidhildenbrand/qemu.git virtio-mem-vfio-v7
> 

Gentle ping.


-- 
Thanks,

David / dhildenb



  parent reply	other threads:[~2021-03-02 16:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24  9:48 [PATCH v7 00/13] virtio-mem: vfio support David Hildenbrand
2021-02-24  9:48 ` [PATCH v7 01/13] memory: Introduce RamDiscardManager for RAM memory regions David Hildenbrand
2021-02-24  9:48 ` [PATCH v7 02/13] memory: Helpers to copy/free a MemoryRegionSection David Hildenbrand
2021-02-24  9:48 ` [PATCH v7 03/13] virtio-mem: Factor out traversing unplugged ranges David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 04/13] virtio-mem: Don't report errors when ram_block_discard_range() fails David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 05/13] virtio-mem: Implement RamDiscardManager interface David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 06/13] vfio: Support for RamDiscardManager in the !vIOMMU case David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 07/13] vfio: Query and store the maximum number of possible DMA mappings David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 08/13] vfio: Sanity check maximum number of DMA mappings with RamDiscardManager David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 09/13] vfio: Support for RamDiscardManager in the vIOMMU case David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 10/13] softmmu/physmem: Don't use atomic operations in ram_block_discard_(disable|require) David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 11/13] softmmu/physmem: Extend ram_block_discard_(require|disable) by two discard types David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 12/13] virtio-mem: Require only coordinated discards David Hildenbrand
2021-02-24  9:49 ` [PATCH v7 13/13] vfio: Disable only uncoordinated discards for VFIO_TYPE1 iommus David Hildenbrand
2021-03-02 16:46 ` David Hildenbrand [this message]
2021-03-05  9:45   ` [PATCH v7 00/13] virtio-mem: vfio support David Hildenbrand
2021-03-19 10:17 ` 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=4c44dd6b-0490-8b70-490a-e456e8e96039@redhat.com \
    --to=david@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mkedzier@redhat.com \
    --cc=mst@redhat.com \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=pankaj.gupta@cloud.ionos.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.