From: David Hildenbrand <david@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"David Hildenbrand" <david@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Halil Pasic" <pasic@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: [PATCH RFC 0/4] kvm: Implement atomic memory region resizes
Date: Tue, 3 Mar 2020 15:19:35 +0100 [thread overview]
Message-ID: <20200303141939.352319-1-david@redhat.com> (raw)
Currently, when doing a
memory_region_ram_resize() -> memory_region_set_size()
the old KVM slot will first get removed and the new, resized one, will be
re-added. This is fine as long as no IOCTL is currently using any data from
such a memory slot (e.g., when building ACPI tables). However, if e.g., a
VCPU is in KVM_RUN and tries to access any data on such a slot while we're
growing it, we will get wrong faults while the slot is temporarily removed.
Let's allow to resize memory regions while the guest is running and might
be using the regions. Inhibit any KVM ioctl while we are replacing the
memory slot(s).
This is a preparation for virtio-mem (initially, x86-64 only), which wants
to resize (esp. grow) ram memory regions while the guest is running via
memory_region_ram_resize().
Using pause_all_vcpus()/resume_all_vcpus() is not possible, as it will
temporarily drop the BQL - something most callers can't handle (esp.
when called from vcpu context e.g., in virtio code).
Once we can handle resizes in the kernel (e.g., via
KVM_SET_USER_MEMORY_REGION), we can make inhibiting optional at runtime.
Instead of inhibiting during the region_resize(), we could inhibit for the
hole memory transaction (from begin() to commit()). This could be nice,
because also splitting of memory regions would be atomic (I remember there
was a BUG report regarding that), however, I am not sure if that might
impact any RT users.
Tested so far with x86-64 KVM only. Thoughts? Anything important I am
missing? Any alternatives that don't require kernel changes?
David Hildenbrand (4):
openpic_kvm: Use kvm_device_ioctl() instead of ioctl()
intc/s390_flic_kvm.c: Use kvm_device_ioctl() instead of ioctl()
memory: Add region_resize() callback to memory notifier
kvm: Implement atomic memory region resizes via region_resize()
accel/kvm/kvm-all.c | 121 +++++++++++++++++++++++++++++++++++++---
hw/intc/openpic_kvm.c | 8 +--
hw/intc/s390_flic_kvm.c | 22 ++++----
include/exec/memory.h | 18 ++++++
include/hw/core/cpu.h | 3 +
memory.c | 72 ++++++++++++++++++++++--
6 files changed, 217 insertions(+), 27 deletions(-)
--
2.24.1
next reply other threads:[~2020-03-03 14:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 14:19 David Hildenbrand [this message]
2020-03-03 14:19 ` [PATCH RFC 1/4] openpic_kvm: Use kvm_device_ioctl() instead of ioctl() David Hildenbrand
2020-03-03 14:19 ` [PATCH RFC 2/4] intc/s390_flic_kvm.c: " David Hildenbrand
2020-03-04 8:22 ` Christian Borntraeger
2020-03-04 8:30 ` David Hildenbrand
2020-03-03 14:19 ` [PATCH RFC 3/4] memory: Add region_resize() callback to memory notifier David Hildenbrand
2020-03-03 14:19 ` [PATCH RFC 4/4] kvm: Implement atomic memory region resizes via region_resize() David Hildenbrand
2020-03-06 9:50 ` Paolo Bonzini
2020-03-06 10:20 ` David Hildenbrand
2020-03-06 11:38 ` Paolo Bonzini
2020-03-06 12:18 ` David Hildenbrand
2020-03-06 14:30 ` David Hildenbrand
2020-03-06 14:39 ` Paolo Bonzini
2020-03-06 14:44 ` 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=20200303141939.352319-1-david@redhat.com \
--to=david@redhat.com \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).