From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
Emanuele Giuseppe Esposito <eesposit@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
kvm@vger.kernel.org, Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, Like Xu <like.xu.linux@gmail.com>
Subject: Re: [RFC PATCH 0/9] kvm: implement atomic memslot updates
Date: Thu, 29 Sep 2022 17:41:59 +0200 [thread overview]
Message-ID: <5a352ff5-5d37-e92d-3d4b-c70a5d11c41b@redhat.com> (raw)
In-Reply-To: <YzW3VxqZTb2hnXCy@google.com>
On 9/29/22 17:18, Sean Christopherson wrote:
> IMO, KVM_MEM_DISABLED or similar is the way to go. I.e. formalize the "restart
> page faults" semantics without taking on the complexity of batched updates.
If userspace has to collaborate, KVM_MEM_DISABLED (or KVM_MEM_USER_EXIT
would be a better name) is not needed either except as an optimization;
you can just kick all CPUs unconditionally.
And in fact KVM_MEM_DISABLED is not particularly easy to implement
either; in order to allow split/merge it should be possible for a new
memslot to replace multiple disabled memslots, in order to allow
merging, and to be only partially overlap the first/last disabled
memslot it replaces.
None of this is allowed for other memslots, so exactly the same metadata
complications exist as for other options such as wholesale replacement
or batched updates. The only semantics with a sane implementation would
be to destroy the dirty bitmap of disabled memslots when they are
replaced. At least it would be possible for userspace to set
KVM_MEM_DISABLED, issue KVM_GET_DIRTY_LOG and then finally create the
new memslot. That would be _correct_, but still not very appealing.
I don't exclude suffering from tunnel vision, but batched updates to me
still seem to be the least bad option.
Paolo
next prev parent reply other threads:[~2022-09-29 15:43 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-09 10:44 [RFC PATCH 0/9] kvm: implement atomic memslot updates Emanuele Giuseppe Esposito
2022-09-09 10:44 ` [RFC PATCH 1/9] kvm_main.c: move slot check in kvm_set_memory_region Emanuele Giuseppe Esposito
2022-09-28 16:41 ` Paolo Bonzini
2022-09-09 10:44 ` [RFC PATCH 2/9] kvm.h: introduce KVM_SET_USER_MEMORY_REGION_LIST ioctl Emanuele Giuseppe Esposito
2022-09-28 16:42 ` Paolo Bonzini
2022-09-09 10:45 ` [RFC PATCH 3/9] kvm_main.c: introduce kvm_internal_memory_region_list Emanuele Giuseppe Esposito
2022-09-28 16:48 ` Paolo Bonzini
2022-09-09 10:45 ` [RFC PATCH 4/9] kvm_main.c: split logic in kvm_set_memslots Emanuele Giuseppe Esposito
2022-09-28 17:04 ` Paolo Bonzini
2022-09-09 10:45 ` [RFC PATCH 5/9] kvm_main.c: split __kvm_set_memory_region logic in kvm_check_mem and kvm_prepare_batch Emanuele Giuseppe Esposito
2022-09-13 2:56 ` Yang, Weijiang
2022-09-18 16:22 ` Emanuele Giuseppe Esposito
2022-09-28 17:11 ` Paolo Bonzini
2022-09-09 10:45 ` [RFC PATCH 6/9] kvm_main.c: simplify change-specific callbacks Emanuele Giuseppe Esposito
2022-09-09 10:45 ` [RFC PATCH 7/9] kvm_main.c: duplicate invalid memslot also in inactive list Emanuele Giuseppe Esposito
2022-09-28 17:18 ` Paolo Bonzini
2022-09-09 10:45 ` [RFC PATCH 8/9] kvm_main.c: find memslots from the inactive memslot list Emanuele Giuseppe Esposito
2022-09-09 10:45 ` [RFC PATCH 9/9] kvm_main.c: handle atomic memslot update Emanuele Giuseppe Esposito
2022-09-13 2:30 ` Yang, Weijiang
2022-09-18 16:18 ` Emanuele Giuseppe Esposito
2022-09-27 7:46 ` David Hildenbrand
2022-09-27 8:35 ` Emanuele Giuseppe Esposito
2022-09-27 9:22 ` David Hildenbrand
2022-09-27 9:32 ` Emanuele Giuseppe Esposito
2022-09-27 14:52 ` David Hildenbrand
2022-09-28 17:29 ` Paolo Bonzini
2022-09-09 14:30 ` [RFC PATCH 0/9] kvm: implement atomic memslot updates Sean Christopherson
2022-09-18 16:13 ` Emanuele Giuseppe Esposito
2022-09-19 7:38 ` Like Xu
2022-09-19 7:53 ` David Hildenbrand
2022-09-19 17:30 ` David Hildenbrand
2022-09-23 13:10 ` Emanuele Giuseppe Esposito
2022-09-23 13:21 ` David Hildenbrand
2022-09-23 13:38 ` Emanuele Giuseppe Esposito
2022-09-26 9:03 ` David Hildenbrand
2022-09-26 21:28 ` Sean Christopherson
2022-09-27 7:38 ` Emanuele Giuseppe Esposito
2022-09-27 15:58 ` Sean Christopherson
2022-09-28 9:11 ` Emanuele Giuseppe Esposito
2022-09-28 11:14 ` Maxim Levitsky
2022-09-28 12:52 ` David Hildenbrand
2022-09-28 15:07 ` Paolo Bonzini
2022-09-28 15:33 ` David Hildenbrand
2022-09-28 15:58 ` Sean Christopherson
2022-09-28 16:38 ` Paolo Bonzini
2022-09-28 20:41 ` Sean Christopherson
2022-09-29 8:05 ` Emanuele Giuseppe Esposito
2022-09-29 8:24 ` David Hildenbrand
2022-09-29 15:18 ` Sean Christopherson
2022-09-29 15:41 ` Paolo Bonzini [this message]
2022-09-29 15:28 ` Paolo Bonzini
2022-09-29 15:40 ` Maxim Levitsky
2022-09-29 16:00 ` David Hildenbrand
2022-09-29 21:39 ` Sean Christopherson
2022-10-13 7:43 ` Emanuele Giuseppe Esposito
2022-10-13 8:44 ` David Hildenbrand
2022-10-13 11:12 ` Emanuele Giuseppe Esposito
2022-10-13 14:45 ` 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=5a352ff5-5d37-e92d-3d4b-c70a5d11c41b@redhat.com \
--to=pbonzini@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=eesposit@redhat.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--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;
as well as URLs for NNTP newsgroup(s).