public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Gavin Shan <gshan@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>,
	kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, shuah@kernel.org, catalin.marinas@arm.com,
	andrew.jones@linux.dev, ajones@ventanamicro.com,
	bgardon@google.com, dmatlack@google.com, will@kernel.org,
	suzuki.poulose@arm.com, alexandru.elisei@arm.com,
	pbonzini@redhat.com, peterx@redhat.com, oliver.upton@linux.dev,
	zhenyzha@redhat.com, shan.gavin@gmail.com
Subject: Re: [PATCH v10 3/7] KVM: Support dirty ring in conjunction with bitmap
Date: Fri, 11 Nov 2022 15:19:04 +0000	[thread overview]
Message-ID: <86h6z5plhz.wl-maz@kernel.org> (raw)
In-Reply-To: <1cfa0286-9a42-edd9-beab-02f95fc440ad@redhat.com>

On Thu, 10 Nov 2022 23:47:41 +0000,
Gavin Shan <gshan@redhat.com> wrote:
> 
> commit b05377ecbe003f12c8b79846fa3a300401dcab68 (HEAD -> kvm/arm64_dirtyring)
> Author: Gavin Shan <gshan@redhat.com>
> Date:   Fri Nov 11 07:13:12 2022 +0800
> 
>     KVM: Push dirty information unconditionally to backup bitmap
>         In mark_page_dirty_in_slot(), we bail out when no running vcpu
> exists and
>     a running vcpu context is strictly required by architecture. It may cause
>     backwards compatible issue. Currently, saving vgic/its tables is the only
>     case where no running vcpu context is required. We may have other unknown
>     cases where no running vcpu context exists and it's reported by the warning
>     message. For this, the application is going to enable the backup bitmap for
>     the unknown cases. However, the dirty information can't be pushed to the
>     backup bitmap even though the backup bitmap has been enabled, until the
>     unknown cases are added to the allowed list of non-running vcpu context
>     with extra code changes to the host kernel.
>         In order to make the new application, where the backup bitmap
> has been
>     enabled, to work with the unchanged host, we continue to push the dirty
>     information to the backup bitmap instead of bailing out early.
>         Suggested-by: Sean Christopherson <seanjc@google.com>
>     Signed-off-by: Gavin Shan <gshan@redhat.com>
> 
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 2719e10dd37d..03e6a38094c1 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -3308,8 +3308,7 @@ void mark_page_dirty_in_slot(struct kvm *kvm,
>         if (WARN_ON_ONCE(vcpu && vcpu->kvm != kvm))
>                 return;
>  -       if
> (WARN_ON_ONCE(!kvm_arch_allow_write_without_running_vcpu(kvm) &&
> !vcpu))
> -               return;
> +       WARN_ON_ONCE(!vcpu && !kvm_arch_allow_write_without_running_vcpu(kvm));

I'm happy with this.

>  #endif
>          if (memslot && kvm_slot_dirty_track_enabled(memslot)) {
> @@ -3318,7 +3317,7 @@ void mark_page_dirty_in_slot(struct kvm *kvm,
>                  if (kvm->dirty_ring_size && vcpu)
>                         kvm_dirty_ring_push(vcpu, slot, rel_gfn);
> -               else
> +               else if (memslot->dirty_bitmap)
>                         set_bit_le(rel_gfn, memslot->dirty_bitmap);

But that I don't get. Or rather, I don't get the commit message that
matches this hunk. Do we want to catch the case where all of the
following are true:

- we don't have a vcpu,
- we're allowed to log non-vcpu dirtying
- we *only* have the ring?

If so, can we please capture that in the commit message?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-11-11 15:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 10:49 [PATCH v10 0/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2022-11-10 10:49 ` [PATCH v10 1/7] KVM: x86: Introduce KVM_REQ_DIRTY_RING_SOFT_FULL Gavin Shan
2022-11-10 10:49 ` [PATCH v10 2/7] KVM: Move declaration of kvm_cpu_dirty_log_size() to kvm_dirty_ring.h Gavin Shan
2022-11-10 10:49 ` [PATCH v10 3/7] KVM: Support dirty ring in conjunction with bitmap Gavin Shan
2022-11-10 16:46   ` Sean Christopherson
2022-11-10 23:47     ` Gavin Shan
2022-11-11 15:19       ` Marc Zyngier [this message]
2022-11-11 22:19         ` Gavin Shan
2022-11-11 23:00           ` Sean Christopherson
2022-11-11 23:43             ` Gavin Shan
2022-11-12  0:18               ` Sean Christopherson
2022-11-12  9:50                 ` Gavin Shan
2022-11-11 23:02           ` Marc Zyngier
2022-11-10 10:49 ` [PATCH v10 4/7] KVM: arm64: Enable ring-based dirty memory tracking Gavin Shan
2023-01-15 11:20   ` Zenghui Yu
2023-01-15 11:56     ` Gavin Shan
2023-01-15 23:55       ` Gavin Shan
2023-01-16  4:09       ` Gavin Shan
2023-01-16  4:54         ` Zenghui Yu
2023-01-16  4:51       ` Zenghui Yu
2022-11-10 10:49 ` [PATCH v10 5/7] KVM: selftests: Use host page size to map ring buffer in dirty_log_test Gavin Shan
2022-11-10 10:49 ` [PATCH v10 6/7] KVM: selftests: Clear dirty ring states between two modes " Gavin Shan
2022-11-10 10:49 ` [PATCH v10 7/7] KVM: selftests: Automate choosing dirty ring size " Gavin Shan
2022-11-10 13:21 ` [PATCH v10 0/7] KVM: arm64: Enable ring-based dirty memory tracking Marc Zyngier

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=86h6z5plhz.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=ajones@ventanamicro.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andrew.jones@linux.dev \
    --cc=bgardon@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dmatlack@google.com \
    --cc=gshan@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=kvmarm@lists.linux.dev \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=seanjc@google.com \
    --cc=shan.gavin@gmail.com \
    --cc=shuah@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --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