All of lore.kernel.org
 help / color / mirror / Atom feed
From: guangrong.xiao@gmail.com
To: pbonzini@redhat.com, mtosatti@redhat.com, avi.kivity@gmail.com,
	rkrcmar@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: [PATCH 5/7] KVM: MMU: allow dirty log without write protect
Date: Wed,  3 May 2017 18:52:22 +0800	[thread overview]
Message-ID: <20170503105224.19049-6-xiaoguangrong@tencent.com> (raw)
In-Reply-To: <20170503105224.19049-1-xiaoguangrong@tencent.com>

From: Xiao Guangrong <xiaoguangrong@tencent.com>

A new flag, KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT, is introduced which
indicates the userspace just wants to get the snapshot of dirty bitmap

During live migration, after all snapshot of dirty bitmap is fetched
from KVM, the guest memory can be write protected by calling
KVM_WRITE_PROTECT_ALL_MEM

Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
---
 arch/x86/kvm/x86.c       |  1 +
 include/uapi/linux/kvm.h |  6 +++++-
 virt/kvm/kvm_main.c      | 15 ++++++++++++---
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dcbeaf4..524c96b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2670,6 +2670,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
  	case KVM_CAP_SPLIT_IRQCHIP:
 	case KVM_CAP_IMMEDIATE_EXIT:
 	case KVM_CAP_X86_WRITE_PROTECT_ALL_MEM:
+	case KVM_CAP_X86_DIRTY_LOG_WITHOUT_WRITE_PROTECT:
 		r = 1;
 		break;
 	case KVM_CAP_ADJUST_CLOCK:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7d4a395..e0f348c 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -443,9 +443,12 @@ struct kvm_interrupt {
 };
 
 /* for KVM_GET_DIRTY_LOG */
+
+#define KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT	0x1
+
 struct kvm_dirty_log {
 	__u32 slot;
-	__u32 padding1;
+	__u32 flags;
 	union {
 		void __user *dirty_bitmap; /* one bit per page */
 		__u64 padding2;
@@ -896,6 +899,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_X86_GUEST_MWAIT 143
 #define KVM_CAP_ARM_USER_IRQ 144
 #define KVM_CAP_X86_WRITE_PROTECT_ALL_MEM 145
+#define KVM_CAP_X86_DIRTY_LOG_WITHOUT_WRITE_PROTECT 146
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 035bc51..c82e4d1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1169,6 +1169,12 @@ int kvm_get_dirty_log_protect(struct kvm *kvm,
 	unsigned long n;
 	unsigned long *dirty_bitmap;
 	unsigned long *dirty_bitmap_buffer;
+	bool write_protect;
+
+	if (log->flags & ~KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT)
+		return -EINVAL;
+
+	write_protect = !(log->flags & KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT);
 
 	as_id = log->slot >> 16;
 	id = (u16)log->slot;
@@ -1196,11 +1202,14 @@ int kvm_get_dirty_log_protect(struct kvm *kvm,
 		if (!dirty_bitmap[i])
 			continue;
 
-		*is_dirty = true;
-
 		mask = xchg(&dirty_bitmap[i], 0);
 		dirty_bitmap_buffer[i] = mask;
 
+		if (!write_protect)
+			continue;
+
+		*is_dirty = true;
+
 		if (mask) {
 			offset = i * BITS_PER_LONG;
 			kvm_arch_mmu_enable_log_dirty_pt_masked(kvm, memslot,
@@ -3155,7 +3164,7 @@ static long kvm_vm_compat_ioctl(struct file *filp,
 				   sizeof(compat_log)))
 			return -EFAULT;
 		log.slot	 = compat_log.slot;
-		log.padding1	 = compat_log.padding1;
+		log.flags	 = compat_log.padding1;
 		log.padding2	 = compat_log.padding2;
 		log.dirty_bitmap = compat_ptr(compat_log.dirty_bitmap);
 
-- 
2.9.3

WARNING: multiple messages have this Message-ID (diff)
From: guangrong.xiao@gmail.com
To: pbonzini@redhat.com, mtosatti@redhat.com, avi.kivity@gmail.com,
	rkrcmar@redhat.com
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: [Qemu-devel] [PATCH 5/7] KVM: MMU: allow dirty log without write protect
Date: Wed,  3 May 2017 18:52:22 +0800	[thread overview]
Message-ID: <20170503105224.19049-6-xiaoguangrong@tencent.com> (raw)
In-Reply-To: <20170503105224.19049-1-xiaoguangrong@tencent.com>

From: Xiao Guangrong <xiaoguangrong@tencent.com>

A new flag, KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT, is introduced which
indicates the userspace just wants to get the snapshot of dirty bitmap

During live migration, after all snapshot of dirty bitmap is fetched
from KVM, the guest memory can be write protected by calling
KVM_WRITE_PROTECT_ALL_MEM

Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
---
 arch/x86/kvm/x86.c       |  1 +
 include/uapi/linux/kvm.h |  6 +++++-
 virt/kvm/kvm_main.c      | 15 ++++++++++++---
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dcbeaf4..524c96b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2670,6 +2670,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
  	case KVM_CAP_SPLIT_IRQCHIP:
 	case KVM_CAP_IMMEDIATE_EXIT:
 	case KVM_CAP_X86_WRITE_PROTECT_ALL_MEM:
+	case KVM_CAP_X86_DIRTY_LOG_WITHOUT_WRITE_PROTECT:
 		r = 1;
 		break;
 	case KVM_CAP_ADJUST_CLOCK:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7d4a395..e0f348c 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -443,9 +443,12 @@ struct kvm_interrupt {
 };
 
 /* for KVM_GET_DIRTY_LOG */
+
+#define KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT	0x1
+
 struct kvm_dirty_log {
 	__u32 slot;
-	__u32 padding1;
+	__u32 flags;
 	union {
 		void __user *dirty_bitmap; /* one bit per page */
 		__u64 padding2;
@@ -896,6 +899,7 @@ struct kvm_ppc_resize_hpt {
 #define KVM_CAP_X86_GUEST_MWAIT 143
 #define KVM_CAP_ARM_USER_IRQ 144
 #define KVM_CAP_X86_WRITE_PROTECT_ALL_MEM 145
+#define KVM_CAP_X86_DIRTY_LOG_WITHOUT_WRITE_PROTECT 146
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 035bc51..c82e4d1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1169,6 +1169,12 @@ int kvm_get_dirty_log_protect(struct kvm *kvm,
 	unsigned long n;
 	unsigned long *dirty_bitmap;
 	unsigned long *dirty_bitmap_buffer;
+	bool write_protect;
+
+	if (log->flags & ~KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT)
+		return -EINVAL;
+
+	write_protect = !(log->flags & KVM_DIRTY_LOG_WITHOUT_WRITE_PROTECT);
 
 	as_id = log->slot >> 16;
 	id = (u16)log->slot;
@@ -1196,11 +1202,14 @@ int kvm_get_dirty_log_protect(struct kvm *kvm,
 		if (!dirty_bitmap[i])
 			continue;
 
-		*is_dirty = true;
-
 		mask = xchg(&dirty_bitmap[i], 0);
 		dirty_bitmap_buffer[i] = mask;
 
+		if (!write_protect)
+			continue;
+
+		*is_dirty = true;
+
 		if (mask) {
 			offset = i * BITS_PER_LONG;
 			kvm_arch_mmu_enable_log_dirty_pt_masked(kvm, memslot,
@@ -3155,7 +3164,7 @@ static long kvm_vm_compat_ioctl(struct file *filp,
 				   sizeof(compat_log)))
 			return -EFAULT;
 		log.slot	 = compat_log.slot;
-		log.padding1	 = compat_log.padding1;
+		log.flags	 = compat_log.padding1;
 		log.padding2	 = compat_log.padding2;
 		log.dirty_bitmap = compat_ptr(compat_log.dirty_bitmap);
 
-- 
2.9.3

  parent reply	other threads:[~2017-05-03 10:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 10:52 [PATCH 0/7] KVM: MMU: fast write protect guangrong.xiao
2017-05-03 10:52 ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 1/7] KVM: MMU: correct the behavior of mmu_spte_update_no_track guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 2/7] KVM: MMU: introduce possible_writable_spte_bitmap guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 3/7] KVM: MMU: introduce kvm_mmu_write_protect_all_pages guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 4/7] KVM: MMU: enable KVM_WRITE_PROTECT_ALL_MEM guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` guangrong.xiao [this message]
2017-05-03 10:52   ` [Qemu-devel] [PATCH 5/7] KVM: MMU: allow dirty log without write protect guangrong.xiao
2017-05-03 10:52 ` [PATCH 6/7] KVM: MMU: clarify fast_pf_fix_direct_spte guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 10:52 ` [PATCH 7/7] KVM: MMU: stop using mmu_spte_get_lockless under mmu-lock guangrong.xiao
2017-05-03 10:52   ` [Qemu-devel] " guangrong.xiao
2017-05-03 12:28 ` [PATCH 0/7] KVM: MMU: fast write protect Paolo Bonzini
2017-05-03 12:28   ` [Qemu-devel] " Paolo Bonzini
2017-05-03 14:50   ` Xiao Guangrong
2017-05-03 14:50     ` [Qemu-devel] " Xiao Guangrong
2017-05-03 14:57     ` Paolo Bonzini
2017-05-03 14:57       ` [Qemu-devel] " Paolo Bonzini
2017-05-04  3:36       ` Xiao Guangrong
2017-05-04  3:36         ` [Qemu-devel] " Xiao Guangrong
2017-05-04  7:06         ` Paolo Bonzini
2017-05-04  7:06           ` [Qemu-devel] " Paolo Bonzini
2017-05-23  2:23           ` Xiao Guangrong
2017-05-23  2:23             ` [Qemu-devel] " Xiao Guangrong
2017-05-29 16:48             ` Paolo Bonzini
2017-05-29 16:48               ` [Qemu-devel] " Paolo Bonzini
2017-06-09  3:19               ` Xiao Guangrong
2017-06-09  3:19                 ` [Qemu-devel] " Xiao Guangrong
2017-06-05  7:36 ` Jay Zhou
2017-06-05  7:36   ` Jay Zhou
2017-06-06  2:56   ` Xiao Guangrong

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=20170503105224.19049-6-xiaoguangrong@tencent.com \
    --to=guangrong.xiao@gmail.com \
    --cc=avi.kivity@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@redhat.com \
    --cc=xiaoguangrong@tencent.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.