diff mbox series

[4/4] KVM: Improve warning report in mark_page_dirty_in_slot()

Message ID 20230116040405.260935-5-gshan@redhat.com
State New
Headers
Series Improve dirty ring warning report |

Commit Message

Gavin Shan Jan. 16, 2023, 4:04 a.m. UTC 
  There are two warning reports about the dirty ring in the function.
We have the wrong assumption that the dirty ring is always enabled when
CONFIG_HAVE_KVM_DIRTY_RING is selected. This leads to warning messages
about the dirty ring is reported even the dirty ring isn't enabled by
the user space. Actually, the expected behaviour is to report the
warning messages only when the dirty ring is enabled, instead of
being configured.

Fix it by enabling the checks and warning reports when the dirty ring
has been enabled by the user space.

Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 include/linux/kvm_dirty_ring.h |  5 +++++
 virt/kvm/kvm_main.c            | 25 ++++++++++++++-----------
 2 files changed, 19 insertions(+), 11 deletions(-)

Comments

Sean Christopherson Jan. 17, 2023, 3:42 p.m. UTC | #1 
On Mon, Jan 16, 2023, Gavin Shan wrote:
> There are two warning reports about the dirty ring in the function.
> We have the wrong assumption that the dirty ring is always enabled when
> CONFIG_HAVE_KVM_DIRTY_RING is selected.

No, it's not a wrong assumption, becuase it's not an assumption.  The intent is
to warn irrespective of dirty ring/log enabling.  The orignal code actually warned
irrespective of dirty ring support[1], again intentionally.  The
CONFIG_HAVE_KVM_DIRTY_RING check was added because s390 can mark pages dirty from
an worker thread[2] and s390 has no plans to support the dirty ring.

The reason for warning even if dirty ring isn't enabled is so that bots can catch
potential KVM bugs without having to set up a dirty ring or enable dirty logging.

[1] 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
[2] e09fccb5435d ("KVM: avoid warning on s390 in mark_page_dirty")
Gavin Shan Jan. 19, 2023, 1:15 a.m. UTC | #2 
Hi Sean,

On 1/18/23 2:42 AM, Sean Christopherson wrote:
> On Mon, Jan 16, 2023, Gavin Shan wrote:
>> There are two warning reports about the dirty ring in the function.
>> We have the wrong assumption that the dirty ring is always enabled when
>> CONFIG_HAVE_KVM_DIRTY_RING is selected.
> 
> No, it's not a wrong assumption, becuase it's not an assumption.  The intent is
> to warn irrespective of dirty ring/log enabling.  The orignal code actually warned
> irrespective of dirty ring support[1], again intentionally.  The
> CONFIG_HAVE_KVM_DIRTY_RING check was added because s390 can mark pages dirty from
> an worker thread[2] and s390 has no plans to support the dirty ring.
> 
> The reason for warning even if dirty ring isn't enabled is so that bots can catch
> potential KVM bugs without having to set up a dirty ring or enable dirty logging.
> 
> [1] 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
> [2] e09fccb5435d ("KVM: avoid warning on s390 in mark_page_dirty")
> 

Thanks for the linker. I was confused when looking at the code, but now it's clear to
me. Thanks for your explanation. How about to add a comment there?

   /*
    * The warning is expected when the dirty ring is configured,
    * but not enabled.
    */

Thanks,
Gavin
Sean Christopherson Jan. 19, 2023, 3:19 p.m. UTC | #3 
On Thu, Jan 19, 2023, Gavin Shan wrote:
> Hi Sean,
> 
> On 1/18/23 2:42 AM, Sean Christopherson wrote:
> > On Mon, Jan 16, 2023, Gavin Shan wrote:
> > > There are two warning reports about the dirty ring in the function.
> > > We have the wrong assumption that the dirty ring is always enabled when
> > > CONFIG_HAVE_KVM_DIRTY_RING is selected.
> > 
> > No, it's not a wrong assumption, becuase it's not an assumption.  The intent is
> > to warn irrespective of dirty ring/log enabling.  The orignal code actually warned
> > irrespective of dirty ring support[1], again intentionally.  The
> > CONFIG_HAVE_KVM_DIRTY_RING check was added because s390 can mark pages dirty from
> > an worker thread[2] and s390 has no plans to support the dirty ring.
> > 
> > The reason for warning even if dirty ring isn't enabled is so that bots can catch
> > potential KVM bugs without having to set up a dirty ring or enable dirty logging.
> > 
> > [1] 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
> > [2] e09fccb5435d ("KVM: avoid warning on s390 in mark_page_dirty")
> > 
> 
> Thanks for the linker. I was confused when looking at the code, but now it's clear to
> me. Thanks for your explanation. How about to add a comment there?
> 
>   /*
>    * The warning is expected when the dirty ring is configured,
>    * but not enabled.
>    */

That's not correct either.  By design, the warning can also fire if the dirty ring
is enabled.  KVM's rule is that writes to guest memory always need to be done in
the context of a running vCPU, with the recently added exception of
kvm_arch_allow_write_without_running_vcpu().  That intent of the warning is to
enforce that rule regardless of the state of the VM.

Concretely, I think you can just drop patches 3 and 4, and just fix the arm64 issues.
Gavin Shan Jan. 19, 2023, 11:06 p.m. UTC | #4 
Hi Sean,

On 1/20/23 2:19 AM, Sean Christopherson wrote:
> On Thu, Jan 19, 2023, Gavin Shan wrote:
>> On 1/18/23 2:42 AM, Sean Christopherson wrote:
>>> On Mon, Jan 16, 2023, Gavin Shan wrote:
>>>> There are two warning reports about the dirty ring in the function.
>>>> We have the wrong assumption that the dirty ring is always enabled when
>>>> CONFIG_HAVE_KVM_DIRTY_RING is selected.
>>>
>>> No, it's not a wrong assumption, becuase it's not an assumption.  The intent is
>>> to warn irrespective of dirty ring/log enabling.  The orignal code actually warned
>>> irrespective of dirty ring support[1], again intentionally.  The
>>> CONFIG_HAVE_KVM_DIRTY_RING check was added because s390 can mark pages dirty from
>>> an worker thread[2] and s390 has no plans to support the dirty ring.
>>>
>>> The reason for warning even if dirty ring isn't enabled is so that bots can catch
>>> potential KVM bugs without having to set up a dirty ring or enable dirty logging.
>>>
>>> [1] 2efd61a608b0 ("KVM: Warn if mark_page_dirty() is called without an active vCPU")
>>> [2] e09fccb5435d ("KVM: avoid warning on s390 in mark_page_dirty")
>>>
>>
>> Thanks for the linker. I was confused when looking at the code, but now it's clear to
>> me. Thanks for your explanation. How about to add a comment there?
>>
>>    /*
>>     * The warning is expected when the dirty ring is configured,
>>     * but not enabled.
>>     */
> 
> That's not correct either.  By design, the warning can also fire if the dirty ring
> is enabled.  KVM's rule is that writes to guest memory always need to be done in
> the context of a running vCPU, with the recently added exception of
> kvm_arch_allow_write_without_running_vcpu().  That intent of the warning is to
> enforce that rule regardless of the state of the VM.
> 
> Concretely, I think you can just drop patches 3 and 4, and just fix the arm64 issues.
> 

Right, the warning report is still expected when dirty ring is enabled. My attempt
was to have comment for the confused case. Anyway, it's not a big deal. I will drop
PATCH[3] and PATCH[4] in v2.

Thanks,
Gavin
diff mbox series

Patch

diff --git a/include/linux/kvm_dirty_ring.h b/include/linux/kvm_dirty_ring.h
index 4862c98d80d3..3fda0aa42858 100644
--- a/include/linux/kvm_dirty_ring.h
+++ b/include/linux/kvm_dirty_ring.h
@@ -42,6 +42,11 @@  static inline bool kvm_use_dirty_bitmap(struct kvm *kvm)
 	return true;
 }
 
+static inline bool kvm_arch_allow_write_without_running_vcpu(struct kvm *kvm)
+{
+	return false;
+}
+
 static inline int kvm_dirty_ring_alloc(struct kvm_dirty_ring *ring,
 				       int index, u32 size)
 {
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 90f538433916..a35c32bc84e1 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3316,26 +3316,29 @@  void mark_page_dirty_in_slot(struct kvm *kvm,
 			     const struct kvm_memory_slot *memslot,
 		 	     gfn_t gfn)
 {
-	struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
+	struct kvm_vcpu *vcpu;
 	unsigned long rel_gfn;
 	u32 slot;
 
-#ifdef CONFIG_HAVE_KVM_DIRTY_RING
-	if (WARN_ON_ONCE(vcpu && vcpu->kvm != kvm))
-		return;
-
-	WARN_ON_ONCE(!vcpu && !kvm_arch_allow_write_without_running_vcpu(kvm));
-#endif
-
 	if (!memslot || !kvm_slot_dirty_track_enabled(memslot))
 		return;
 
 	rel_gfn = gfn - memslot->base_gfn;
 	slot = (memslot->as_id << 16) | memslot->id;
 
-	if (kvm->dirty_ring_size && vcpu)
-		kvm_dirty_ring_push(vcpu, slot, rel_gfn);
-	else if (memslot->dirty_bitmap)
+	if (kvm->dirty_ring_size) {
+		vcpu = kvm_get_running_vcpu();
+		if (vcpu) {
+			if (!WARN_ON_ONCE(vcpu->kvm != kvm))
+				kvm_dirty_ring_push(vcpu, slot, rel_gfn);
+
+			return;
+		}
+
+		WARN_ON_ONCE(!kvm_arch_allow_write_without_running_vcpu(kvm));
+	}
+
+	if (memslot->dirty_bitmap)
 		set_bit_le(rel_gfn, memslot->dirty_bitmap);
 }
 EXPORT_SYMBOL_GPL(mark_page_dirty_in_slot);