All of lore.kernel.org
 help / color / mirror / Atom feed
From: Binbin Wu <binbin.wu@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Peter Xu <peterx@redhat.com>, Yan Zhao <yan.y.zhao@intel.com>,
	Maxim Levitsky <mlevitsk@redhat.com>
Subject: Re: [PATCH v2 4/5] KVM: Check for empty mask of harvested dirty ring entries in caller
Date: Tue, 13 May 2025 17:17:52 +0800	[thread overview]
Message-ID: <458bb0e1-ed50-449c-b884-a825eb09b7fe@linux.intel.com> (raw)
In-Reply-To: <20250508141012.1411952-5-seanjc@google.com>



On 5/8/2025 10:10 PM, Sean Christopherson wrote:
> When resetting a dirty ring, explicitly check that there is work to be
> done before calling kvm_reset_dirty_gfn(), e.g. if no harvested entries
> are found and/or on the loop's first iteration, and delete the extremely
> misleading comment "This is only needed to make compilers happy".  KVM
> absolutely relies on mask to be zero-initialized, i.e. the comment is an
> outright lie.  Furthermore, the compiler is right to complain that KVM is
> calling a function with uninitialized data, as there are no guarantees
> the implementation details of kvm_reset_dirty_gfn() will be visible to
> kvm_dirty_ring_reset().
>
> While the flaw could be fixed by simply deleting (or rewording) the
> comment, and duplicating the check is unfortunate, checking mask in the
> caller will allow for additional cleanups.
>
> Opportunisticaly drop the zero-initialization of cur_slot and cur_offset.

Opportunisticaly -> Opportunistically


> If a bug were introduced where either the slot or offset was consumed
> before mask is set to a non-zero value, then it is highly desirable for
> the compiler (or some other sanitizer) to yell.
>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Yan Zhao <yan.y.zhao@intel.com>
> Cc: Maxim Levitsky <mlevitsk@redhat.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
>   virt/kvm/dirty_ring.c | 44 ++++++++++++++++++++++++++++++++++---------
>   1 file changed, 35 insertions(+), 9 deletions(-)
>
[...]
>   
> -	kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask);
> +	/*
> +	 * Perform a final reset if there are harvested entries that haven't
> +	 * been processed, which is guaranteed if at least one harvested was
> +	 * found.  The loop only performs a reset when the "next" entry can't
> +	 * be batched with "current" the entry(s), and that reset processes the
"current" the entry(s) -> the "current" entry(s) ?

> +	 * _current_ entry(s), i.e. the last harvested entry, a.k.a. next, will
> +	 * always be left pending.
> +	 */
> +	if (mask)
> +		kvm_reset_dirty_gfn(kvm, cur_slot, cur_offset, mask);
>   
>   	/*
>   	 * The request KVM_REQ_DIRTY_RING_SOFT_FULL will be cleared


  reply	other threads:[~2025-05-13  9:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 14:10 [PATCH v2 0/5] KVM: Dirty ring fixes and cleanups Sean Christopherson
2025-05-08 14:10 ` [PATCH v2 1/5] KVM: Bound the number of dirty ring entries in a single reset at INT_MAX Sean Christopherson
2025-05-13  1:25   ` Binbin Wu
2025-05-08 14:10 ` [PATCH v2 2/5] KVM: Bail from the dirty ring reset flow if a signal is pending Sean Christopherson
2025-05-08 14:10 ` [PATCH v2 3/5] KVM: Conditionally reschedule when resetting the dirty ring Sean Christopherson
2025-05-12 22:02   ` James Houghton
2025-05-13 14:13     ` Sean Christopherson
2025-05-13 22:27       ` James Houghton
2025-05-14 14:24         ` Sean Christopherson
2025-05-08 14:10 ` [PATCH v2 4/5] KVM: Check for empty mask of harvested dirty ring entries in caller Sean Christopherson
2025-05-13  9:17   ` Binbin Wu [this message]
2025-05-13 12:51   ` Gupta, Pankaj
2025-05-08 14:10 ` [PATCH v2 5/5] KVM: Use mask of harvested dirty ring entries to coalesce dirty ring resets Sean Christopherson
2025-05-12 22:33   ` James Houghton
2025-05-13 12:16   ` Gupta, Pankaj

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=458bb0e1-ed50-449c-b884-a825eb09b7fe@linux.intel.com \
    --to=binbin.wu@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=seanjc@google.com \
    --cc=yan.y.zhao@intel.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.