All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Gavin Shan <gshan@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
	peter.maydell@linaro.org, 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: Re: [PATCH v1 3/6] kvm: Synchronize the backup bitmap in the last stage
Date: Tue, 21 Feb 2023 12:46:22 -0500	[thread overview]
Message-ID: <Y/UDbqyB2N/OWWi5@x1n> (raw)
In-Reply-To: <20230213003925.40158-4-gshan@redhat.com>

On Mon, Feb 13, 2023 at 08:39:22AM +0800, Gavin Shan wrote:
> In the last stage of live migration or memory slot removal, the
> backup bitmap needs to be synchronized when it has been enabled.
> 
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
>  accel/kvm/kvm-all.c      | 11 +++++++++++
>  include/sysemu/kvm_int.h |  1 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
> index 01a6a026af..b5e12de522 100644
> --- a/accel/kvm/kvm-all.c
> +++ b/accel/kvm/kvm-all.c
> @@ -1352,6 +1352,10 @@ static void kvm_set_phys_mem(KVMMemoryListener *kml,
>                   */
>                  if (kvm_state->kvm_dirty_ring_size) {
>                      kvm_dirty_ring_reap_locked(kvm_state, NULL);
> +                    if (kvm_state->kvm_dirty_ring_with_bitmap) {
> +                        kvm_slot_sync_dirty_pages(mem);
> +                        kvm_slot_get_dirty_log(kvm_state, mem);
> +                    }
>                  } else {
>                      kvm_slot_get_dirty_log(kvm_state, mem);
>                  }

IIUC after the memory atomic update changes lands QEMU, we may not need
this sync at all.

My understanding is that we sync dirty log here only because of non-atomic
updates happening in the past and we may lose dirty bits unexpectedly.
Maybe Paolo knows.

But that needs some more justification and history digging, so definitely
more suitable to leave it for later and separate discussion.

Reviewed-by: Peter Xu <peterx@redhat.com>

Thanks,

> @@ -1573,6 +1577,12 @@ static void kvm_log_sync_global(MemoryListener *l, bool last_stage)
>          mem = &kml->slots[i];
>          if (mem->memory_size && mem->flags & KVM_MEM_LOG_DIRTY_PAGES) {
>              kvm_slot_sync_dirty_pages(mem);
> +
> +            if (s->kvm_dirty_ring_with_bitmap && last_stage &&
> +                kvm_slot_get_dirty_log(s, mem)) {
> +                kvm_slot_sync_dirty_pages(mem);
> +            }
> +
>              /*
>               * This is not needed by KVM_GET_DIRTY_LOG because the
>               * ioctl will unconditionally overwrite the whole region.
> @@ -3701,6 +3711,7 @@ static void kvm_accel_instance_init(Object *obj)
>      s->kernel_irqchip_split = ON_OFF_AUTO_AUTO;
>      /* KVM dirty ring is by default off */
>      s->kvm_dirty_ring_size = 0;
> +    s->kvm_dirty_ring_with_bitmap = false;
>      s->notify_vmexit = NOTIFY_VMEXIT_OPTION_RUN;
>      s->notify_window = 0;
>  }
> diff --git a/include/sysemu/kvm_int.h b/include/sysemu/kvm_int.h
> index 60b520a13e..fdd5b1bde0 100644
> --- a/include/sysemu/kvm_int.h
> +++ b/include/sysemu/kvm_int.h
> @@ -115,6 +115,7 @@ struct KVMState
>      } *as;
>      uint64_t kvm_dirty_ring_bytes;  /* Size of the per-vcpu dirty ring */
>      uint32_t kvm_dirty_ring_size;   /* Number of dirty GFNs per ring */
> +    bool kvm_dirty_ring_with_bitmap;
>      struct KVMDirtyRingReaper reaper;
>      NotifyVmexitOption notify_vmexit;
>      uint32_t notify_window;
> -- 
> 2.23.0
> 

-- 
Peter Xu



  reply	other threads:[~2023-02-21 17:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13  0:39 [PATCH v1 0/6] hw/arm/virt: Support dirty ring Gavin Shan
2023-02-13  0:39 ` [PATCH v1 1/6] linux-headers: Update for " Gavin Shan
2023-02-21 16:30   ` Peter Maydell
2023-02-21 23:18     ` Gavin Shan
2023-02-22  8:49       ` Cornelia Huck
2023-02-22  9:03         ` Gavin Shan
2023-02-13  0:39 ` [PATCH v1 2/6] migration: Add last stage indicator to global dirty log synchronization Gavin Shan
2023-02-21 17:36   ` Peter Xu
2023-02-21 23:20     ` Gavin Shan
2023-02-13  0:39 ` [PATCH v1 3/6] kvm: Synchronize the backup bitmap in the last stage Gavin Shan
2023-02-21 17:46   ` Peter Xu [this message]
2023-02-21 23:44     ` Gavin Shan
2023-02-21 23:58       ` Peter Xu
2023-02-22  6:06         ` Gavin Shan
2023-02-13  0:39 ` [PATCH v1 4/6] kvm: Add helper kvm_dirty_ring_init() Gavin Shan
2023-02-21 20:12   ` Peter Xu
2023-02-13  0:39 ` [PATCH v1 5/6] hw/arm/virt: Enable backup bitmap for dirty ring Gavin Shan
2023-02-21 16:27   ` Peter Maydell
2023-02-22  4:35     ` Gavin Shan
2023-02-22 15:54       ` Peter Maydell
2023-02-23  0:52         ` Gavin Shan
2023-02-23 11:51           ` Peter Maydell
2023-02-24 10:19             ` Gavin Shan
2023-02-13  0:39 ` [PATCH v1 6/6] kvm: Enable dirty ring for arm64 Gavin Shan
2023-02-17  1:59 ` [PATCH v1 0/6] hw/arm/virt: Support dirty ring Zhenyu Zhang

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=Y/UDbqyB2N/OWWi5@x1n \
    --to=peterx@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=gshan@redhat.com \
    --cc=maz@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 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.