From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel@nongnu.org
Cc: Ani Sinha <anisinha@redhat.com>
Subject: [PULL 18/23] accel/kvm: refactor dirty ring setup
Date: Fri, 4 Oct 2024 18:34:10 +0200 [thread overview]
Message-ID: <20241004163415.951106-19-pbonzini@redhat.com> (raw)
In-Reply-To: <20241004163415.951106-1-pbonzini@redhat.com>
From: Ani Sinha <anisinha@redhat.com>
Refactor setting up of dirty ring code in kvm_init() so that is can be
reused in the future patchsets.
Signed-off-by: Ani Sinha <anisinha@redhat.com>
Link: https://lore.kernel.org/r/20240912061838.4501-1-anisinha@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
accel/kvm/kvm-all.c | 88 +++++++++++++++++++++++++--------------------
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index e06cf3a4157..e57492fda5c 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2435,6 +2435,55 @@ static int find_kvm_machine_type(MachineState *ms)
return type;
}
+static int kvm_setup_dirty_ring(KVMState *s)
+{
+ uint64_t dirty_log_manual_caps;
+ int ret;
+
+ /*
+ * Enable KVM dirty ring if supported, otherwise fall back to
+ * dirty logging mode
+ */
+ ret = kvm_dirty_ring_init(s);
+ if (ret < 0) {
+ return ret;
+ }
+
+ /*
+ * KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is not needed when dirty ring is
+ * enabled. More importantly, KVM_DIRTY_LOG_INITIALLY_SET will assume no
+ * page is wr-protected initially, which is against how kvm dirty ring is
+ * usage - kvm dirty ring requires all pages are wr-protected at the very
+ * beginning. Enabling this feature for dirty ring causes data corruption.
+ *
+ * TODO: Without KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 and kvm clear dirty log,
+ * we may expect a higher stall time when starting the migration. In the
+ * future we can enable KVM_CLEAR_DIRTY_LOG to work with dirty ring too:
+ * instead of clearing dirty bit, it can be a way to explicitly wr-protect
+ * guest pages.
+ */
+ if (!s->kvm_dirty_ring_size) {
+ dirty_log_manual_caps =
+ kvm_check_extension(s, KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2);
+ dirty_log_manual_caps &= (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE |
+ KVM_DIRTY_LOG_INITIALLY_SET);
+ s->manual_dirty_log_protect = dirty_log_manual_caps;
+ if (dirty_log_manual_caps) {
+ ret = kvm_vm_enable_cap(s, KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2, 0,
+ dirty_log_manual_caps);
+ if (ret) {
+ warn_report("Trying to enable capability %"PRIu64" of "
+ "KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 but failed. "
+ "Falling back to the legacy mode. ",
+ dirty_log_manual_caps);
+ s->manual_dirty_log_protect = 0;
+ }
+ }
+ }
+
+ return 0;
+}
+
static int kvm_init(MachineState *ms)
{
MachineClass *mc = MACHINE_GET_CLASS(ms);
@@ -2454,7 +2503,6 @@ static int kvm_init(MachineState *ms)
const KVMCapabilityInfo *missing_cap;
int ret;
int type;
- uint64_t dirty_log_manual_caps;
qemu_mutex_init(&kml_slots_lock);
@@ -2566,47 +2614,11 @@ static int kvm_init(MachineState *ms)
s->coalesced_pio = s->coalesced_mmio &&
kvm_check_extension(s, KVM_CAP_COALESCED_PIO);
- /*
- * Enable KVM dirty ring if supported, otherwise fall back to
- * dirty logging mode
- */
- ret = kvm_dirty_ring_init(s);
+ ret = kvm_setup_dirty_ring(s);
if (ret < 0) {
goto err;
}
- /*
- * KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is not needed when dirty ring is
- * enabled. More importantly, KVM_DIRTY_LOG_INITIALLY_SET will assume no
- * page is wr-protected initially, which is against how kvm dirty ring is
- * usage - kvm dirty ring requires all pages are wr-protected at the very
- * beginning. Enabling this feature for dirty ring causes data corruption.
- *
- * TODO: Without KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 and kvm clear dirty log,
- * we may expect a higher stall time when starting the migration. In the
- * future we can enable KVM_CLEAR_DIRTY_LOG to work with dirty ring too:
- * instead of clearing dirty bit, it can be a way to explicitly wr-protect
- * guest pages.
- */
- if (!s->kvm_dirty_ring_size) {
- dirty_log_manual_caps =
- kvm_check_extension(s, KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2);
- dirty_log_manual_caps &= (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE |
- KVM_DIRTY_LOG_INITIALLY_SET);
- s->manual_dirty_log_protect = dirty_log_manual_caps;
- if (dirty_log_manual_caps) {
- ret = kvm_vm_enable_cap(s, KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2, 0,
- dirty_log_manual_caps);
- if (ret) {
- warn_report("Trying to enable capability %"PRIu64" of "
- "KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 but failed. "
- "Falling back to the legacy mode. ",
- dirty_log_manual_caps);
- s->manual_dirty_log_protect = 0;
- }
- }
- }
-
#ifdef KVM_CAP_VCPU_EVENTS
s->vcpu_events = kvm_check_extension(s, KVM_CAP_VCPU_EVENTS);
#endif
--
2.46.1
next prev parent reply other threads:[~2024-10-04 16:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 16:33 [PULL 00/23] Misc patches for 2024-10-04 Paolo Bonzini
2024-10-04 16:33 ` [PULL 01/23] target/i386: Delete duplicated macro definition CR4_FRED_MASK Paolo Bonzini
2024-10-04 16:33 ` [PULL 02/23] target/i386: Add VMX control bits for nested FRED support Paolo Bonzini
2024-10-04 16:33 ` [PULL 03/23] target/i386: Raise the highest index value used for any VMCS encoding Paolo Bonzini
2024-10-04 16:33 ` [PULL 04/23] tests/unit: remove block layer code from test-nested-aio-poll Paolo Bonzini
2024-10-04 16:33 ` [PULL 05/23] hw/i386/pc: Add a description for the i8042 property Paolo Bonzini
2024-10-04 16:33 ` [PULL 06/23] kvm/i386: make kvm_filter_msr() and related definitions private to kvm module Paolo Bonzini
2024-10-04 16:33 ` [PULL 07/23] kvm/i386: fix return values of is_host_cpu_intel() Paolo Bonzini
2024-10-04 16:34 ` [PULL 08/23] kvm: replace fprintf with error_report()/printf() in kvm_init() Paolo Bonzini
2024-10-04 16:34 ` [PULL 09/23] kvm/i386: refactor kvm_arch_init and split it into smaller functions Paolo Bonzini
2024-10-04 16:34 ` [PULL 10/23] kvm/i386: replace identity_base variable with a constant Paolo Bonzini
2024-10-04 16:34 ` [PULL 11/23] kvm: refactor core virtual machine creation into its own function Paolo Bonzini
2024-10-04 16:34 ` [PULL 12/23] target/i386: Expose IBPB-BRTYPE and SBPB CPUID bits to the guest Paolo Bonzini
2024-10-04 16:34 ` [PULL 13/23] hw: Remove unused inclusion of hw/char/serial.h Paolo Bonzini
2024-10-04 16:34 ` [PULL 14/23] hw/char/serial.h: Extract serial-isa.h Paolo Bonzini
2024-10-04 16:34 ` [PULL 15/23] hw/char: Extract serial-mm Paolo Bonzini
2024-10-04 16:34 ` [PULL 16/23] 9p: remove 'proxy' filesystem backend driver Paolo Bonzini
2024-10-04 16:34 ` [PULL 17/23] minikconf: print error entirely on stderr Paolo Bonzini
2024-10-04 16:34 ` Paolo Bonzini [this message]
2024-10-04 16:34 ` [PULL 19/23] kvm: Allow kvm_arch_get/put_registers to accept Error** Paolo Bonzini
2024-10-04 16:34 ` [PULL 20/23] target/i386/kvm: Report which action failed in kvm_arch_put/get_registers Paolo Bonzini
2024-10-04 16:34 ` [PULL 21/23] qom: rename object_resolve_path_type() "ambiguousp" Paolo Bonzini
2024-10-04 16:34 ` [PULL 22/23] qom: set *ambiguous on all paths Paolo Bonzini
2024-10-04 16:34 ` [PULL 23/23] qom: update object_resolve_path*() documentation Paolo Bonzini
2024-10-06 14:10 ` [PULL 00/23] Misc patches for 2024-10-04 Peter Maydell
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=20241004163415.951106-19-pbonzini@redhat.com \
--to=pbonzini@redhat.com \
--cc=anisinha@redhat.com \
--cc=qemu-devel@nongnu.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).