From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Igor Kotrasinski <i.kotrasinsk@partner.samsung.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel@nongnu.org,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Murilo Opsfelder Araujo <muriloo@linux.ibm.com>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()
Date: Fri, 28 Feb 2020 14:42:57 -0500 [thread overview]
Message-ID: <20200228194257.GV180973@xz-x1> (raw)
In-Reply-To: <20200227101205.5616-13-david@redhat.com>
On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
> Let's implement ram_block_resized(), allowing resizeable mappings.
>
> For resizeable mappings, we reserve $max_size IOVA address space, but only
> map $size of it. When resizing, unmap the old part and remap the new
> part. We'll need a new ioctl to do this atomically (e.g., to resize
> while the guest is running - not allowed for now).
Curious: I think it's true for now because resizing only happens
during reboot or destination VM during migration (but before
switching). However is that guaranteed too in the future?
[...]
> @@ -631,7 +658,7 @@ int qemu_vfio_dma_map(QEMUVFIOState *s, void *host, size_t size,
> qemu_vfio_remove_mapping(s, mapping);
> goto out;
> }
> - s->low_water_mark += size;
> + s->low_water_mark += max_size;
I think it's fine to only increase the low water mark here, however
imo it would be better to also cache the max size in IOVAMapping too,
then in resize() we double check new_size <= max_size? It also makes
IOVAMapping more self contained.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2020-02-28 19:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 10:11 [PATCH v3 00/15] Ram blocks with resizeable anonymous allocations under POSIX David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 01/15] util: vfio-helpers: Fix qemu_vfio_close() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 02/15] util: vfio-helpers: Remove Error parameter from qemu_vfio_undo_mapping() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 03/15] util: vfio-helpers: Factor out removal " David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 04/15] exec: Factor out setting ram settings (madvise ...) into qemu_ram_apply_settings() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 05/15] exec: Reuse qemu_ram_apply_settings() in qemu_ram_remap() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 06/15] exec: Drop "shared" parameter from ram_block_add() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 07/15] util/mmap-alloc: Factor out calculation of the pagesize for the guard page David Hildenbrand
2020-02-28 19:43 ` Peter Xu
2020-02-27 10:11 ` [PATCH v3 08/15] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve() David Hildenbrand
2020-02-27 10:11 ` [PATCH v3 09/15] util/mmap-alloc: Factor out populating of memory to mmap_populate() David Hildenbrand
2020-03-03 8:43 ` David Hildenbrand
2020-02-27 10:12 ` [PATCH v3 10/15] util/mmap-alloc: Prepare for resizeable mmaps David Hildenbrand
2020-02-27 10:12 ` [PATCH v3 11/15] util/mmap-alloc: Implement " David Hildenbrand
2020-02-28 19:43 ` Peter Xu
2020-02-27 10:12 ` [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized() David Hildenbrand
2020-02-28 19:42 ` Peter Xu [this message]
2020-02-28 20:16 ` David Hildenbrand
2020-02-28 21:01 ` Peter Xu
2020-03-02 15:01 ` David Hildenbrand
2020-02-28 19:55 ` Peter Xu
2020-02-28 20:19 ` David Hildenbrand
2020-02-28 20:49 ` Peter Xu
2020-02-28 20:56 ` David Hildenbrand
2020-02-27 10:12 ` [PATCH v3 13/15] util: oslib: Resizeable anonymous allocations under POSIX David Hildenbrand
2020-02-28 20:11 ` Peter Xu
2020-02-27 10:12 ` [PATCH v3 14/15] numa: Introduce ram_block_notifiers_support_resize() David Hildenbrand
2020-02-28 20:11 ` Peter Xu
2020-02-27 10:12 ` [PATCH v3 15/15] exec: Ram blocks with resizeable anonymous allocations under POSIX David Hildenbrand
2020-02-28 20:21 ` Peter Xu
2020-03-02 15:27 ` 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=20200228194257.GV180973@xz-x1 \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=i.kotrasinsk@partner.samsung.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=muriloo@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.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).