From: Gavin Shan <gshan@redhat.com>
To: qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com,
peter.maydell@linaro.org, peterx@redhat.com, david@redhat.com,
philmd@linaro.org, mst@redhat.com, cohuck@redhat.com,
quintela@redhat.com, dgilbert@redhat.com, maz@kernel.org,
zhenyzha@redhat.com, shan.gavin@gmail.com
Subject: [PATCH v2 0/4] hw/arm/virt: Support dirty ring
Date: Mon, 27 Feb 2023 12:26:25 +0800 [thread overview]
Message-ID: <20230227042629.339747-1-gshan@redhat.com> (raw)
This series intends to support dirty ring for live migration for arm64. The
dirty ring use discrete buffer to track dirty pages. For arm64, the speciality
is to use backup bitmap to track dirty pages when there is no-running-vcpu
context. It's known that the backup bitmap needs to be synchronized when
KVM device "kvm-arm-gicv3" or "arm-its-kvm" has been enabled. The backup
bitmap is collected in the last stage of migration. The policy here is to
always enable the backup bitmap extension. The overhead to synchronize the
backup bitmap in the last stage of migration, when those two devices aren't
used, is introduced. However, the overhead should be very small and acceptable.
The benefit is to support future cases where those two devices are used without
modifying the code.
PATCH[1] add migration last stage indicator
PATCH[2] synchronize the backup bitmap in the last stage of migration
PATCH[3] add helper kvm_dirty_ring_init() to enable dirty ring
PATCH[4] enable dirty ring for arm64
v1: https://lists.nongnu.org/archive/html/qemu-arm/2023-02/msg00434.html
RFCv1: https://lists.nongnu.org/archive/html/qemu-arm/2023-02/msg00171.html
Testing
=======
(1) kvm-unit-tests/its-pending-migration and kvm-unit-tests/its-migration with
dirty ring or normal dirty page tracking mechanism. All test cases passed.
QEMU=./qemu.main/build/qemu-system-aarch64 ACCEL=kvm \
./its-pending-migration
QEMU=./qemu.main/build/qemu-system-aarch64 ACCEL=kvm \
./its-migration
QEMU=./qemu.main/build/qemu-system-aarch64 ACCEL=kvm,dirty-ring-size=65536 \
./its-pending-migration
QEMU=./qemu.main/build/qemu-system-aarch64 ACCEL=kvm,dirty-ring-size=65536 \
./its-migration
(2) Combinations of migration, post-copy migration, e1000e and virtio-net
devices. All test cases passed.
-netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-device e1000e,bus=pcie.5,netdev=net0,mac=52:54:00:f1:26:a0
-netdev tap,id=vnet0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-device virtio-net-pci,bus=pcie.6,netdev=vnet0,mac=52:54:00:f1:26:b0
Changelog
=========
v2:
* Drop PATCH[v1 1/6] to synchronize linux-headers (Gavin)
* More restrictive comments about struct MemoryListener::log_sync_global (PeterX)
* Always enable the backup bitmap extension (PeterM)
v1:
* Combine two patches into one PATCH[v1 2/6] for the last stage indicator (PeterX)
* Drop the secondary bitmap and use the original one directly (Juan)
* Avoid "goto out" in helper kvm_dirty_ring_init() (Juan)
Gavin Shan (4):
migration: Add last stage indicator to global dirty log
synchronization
kvm: Synchronize the backup bitmap in the last stage
kvm: Add helper kvm_dirty_ring_init()
kvm: Enable dirty ring for arm64
accel/kvm/kvm-all.c | 108 ++++++++++++++++++++++++++++-----------
include/exec/memory.h | 7 ++-
include/sysemu/kvm_int.h | 1 +
migration/dirtyrate.c | 4 +-
migration/ram.c | 20 ++++----
softmmu/memory.c | 10 ++--
6 files changed, 101 insertions(+), 49 deletions(-)
--
2.23.0
next reply other threads:[~2023-02-27 4:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 4:26 Gavin Shan [this message]
2023-02-27 4:26 ` [PATCH v2 1/4] migration: Add last stage indicator to global dirty log synchronization Gavin Shan
2023-02-27 4:26 ` [PATCH v2 2/4] kvm: Synchronize the backup bitmap in the last stage Gavin Shan
2023-02-27 4:26 ` [PATCH v2 3/4] kvm: Add helper kvm_dirty_ring_init() Gavin Shan
2023-02-27 4:26 ` [PATCH v2 4/4] kvm: Enable dirty ring for arm64 Gavin Shan
2023-03-13 7:13 ` [PATCH v2 0/4] hw/arm/virt: Support dirty ring Gavin Shan
2023-03-14 17:05 ` 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=20230227042629.339747-1-gshan@redhat.com \
--to=gshan@redhat.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=maz@kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=shan.gavin@gmail.com \
--cc=zhenyzha@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).