From: Emanuele Giuseppe Esposito <eesposit@redhat.com>
To: kvm@vger.kernel.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Maxim Levitsky <mlevitsk@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Emanuele Giuseppe Esposito <eesposit@redhat.com>
Subject: [PATCH 0/4] KVM: API to block and resume all running vcpus in a vm
Date: Sat, 22 Oct 2022 11:48:15 -0400 [thread overview]
Message-ID: <20221022154819.1823133-1-eesposit@redhat.com> (raw)
This new API allows the userspace to stop all running
vcpus using KVM_KICK_ALL_RUNNING_VCPUS ioctl, and resume them with
KVM_RESUME_ALL_KICKED_VCPUS.
A "running" vcpu is a vcpu that is executing the KVM_RUN ioctl.
This serie is especially helpful to userspace hypervisors like
QEMU when they need to perform operations on memslots without the
risk of having a vcpu reading them in the meanwhile.
With "memslots operations" we mean grow, shrink, merge and split
memslots, which are not "atomic" because there is a time window
between the DELETE memslot operation and the CREATE one.
Currently, each memslot operation is performed with one or more
ioctls.
For example, merging two memslots into one would imply:
DELETE(m1)
DELETE(m2)
CREATE(m1+m2)
And a vcpu could attempt to read m2 right after it is deleted, but
before the new one is created.
Therefore the simplest solution is to pause all vcpus in the kvm
side, so that:
- userspace just needs to call the new API before making memslots
changes, keeping modifications to the minimum
- dirty page updates are also performed when vcpus are blocked, so
there is no time window between the dirty page ioctl and memslots
modifications, since vcpus are all stopped.
- no need to modify the existing memslots API
Emanuele Giuseppe Esposito (4):
linux-headers/linux/kvm.h: introduce kvm_userspace_memory_region_list
ioctl
KVM: introduce kvm_clear_all_cpus_request
KVM: introduce memory transaction semaphore
KVM: use signals to abort enter_guest/blocking and retry
Documentation/virt/kvm/vcpu-requests.rst | 3 ++
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/x86.c | 8 +++++
include/uapi/linux/kvm.h | 3 ++
virt/kvm/kvm_main.c | 45 ++++++++++++++++++++++++
5 files changed, 61 insertions(+)
--
2.31.1
next reply other threads:[~2022-10-22 15:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-22 15:48 Emanuele Giuseppe Esposito [this message]
2022-10-22 15:48 ` [PATCH 1/4] linux-headers/linux/kvm.h: introduce kvm_userspace_memory_region_list ioctl Emanuele Giuseppe Esposito
2022-10-22 15:48 ` [PATCH 2/4] KVM: introduce kvm_clear_all_cpus_request Emanuele Giuseppe Esposito
2022-10-22 15:48 ` [PATCH 3/4] KVM: introduce memory transaction semaphore Emanuele Giuseppe Esposito
2022-10-23 17:50 ` Paolo Bonzini
2022-10-24 12:57 ` Emanuele Giuseppe Esposito
2022-10-25 10:01 ` Paolo Bonzini
2022-10-22 15:48 ` [PATCH 4/4] KVM: use signals to abort enter_guest/blocking and retry Emanuele Giuseppe Esposito
2022-10-23 17:48 ` Paolo Bonzini
2022-10-24 7:43 ` Emanuele Giuseppe Esposito
2022-10-24 7:49 ` Emanuele Giuseppe Esposito
2022-10-25 10:05 ` Paolo Bonzini
2022-10-24 7:56 ` [PATCH 0/4] KVM: API to block and resume all running vcpus in a vm Christian Borntraeger
2022-10-24 8:33 ` Emanuele Giuseppe Esposito
2022-10-24 9:09 ` Christian Borntraeger
2022-10-24 22:45 ` Sean Christopherson
2022-10-25 9:33 ` Paolo Bonzini
2022-10-25 15:55 ` Sean Christopherson
2022-10-25 21:34 ` Paolo Bonzini
2022-10-25 23:07 ` Sean Christopherson
2022-10-26 17:52 ` Hyper-V VTLs, permission bitmaps and userspace exits (was Re: [PATCH 0/4] KVM: API to block and resume all running vcpus in a vm) Paolo Bonzini
2022-10-26 19:33 ` Sean Christopherson
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=20221022154819.1823133-1-eesposit@redhat.com \
--to=eesposit@redhat.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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