All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Haozhong Zhang <haozhong.zhang@intel.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [Qemu-devel] [PATCH] exec: fix access to ram_list.dirty_memory when sync dirty bitmap
Date: Wed, 28 Jun 2017 09:30:01 +0200	[thread overview]
Message-ID: <87zics7eo6.fsf@secure.mitica> (raw)
In-Reply-To: <20170628024358.29956-1-haozhong.zhang@intel.com> (Haozhong Zhang's message of "Wed, 28 Jun 2017 10:43:58 +0800")

Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> In cpu_physical_memory_sync_dirty_bitmap(rb, start, ...), the 2nd
> argument 'start' is relative to the start of the ramblock 'rb'. When
> it's used to access the dirty memory bitmap of ram_list (i.e.
> ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION]->blocks[]), an offset to
> the start of all RAM (i.e. rb->offset) should be added to it, which has
> however been missed since c/s 6b6712efcc. For a ramblock of host memory
> backend whose offset is not zero, cpu_physical_memory_sync_dirty_bitmap()
> synchronizes the incorrect part of the dirty memory bitmap of ram_list
> to the per ramblock dirty bitmap. As a result, a guest with host
> memory backend may crash after migration.
>
> Fix it by adding the offset of ramblock when accessing the dirty memory
> bitmap of ram_list in cpu_physical_memory_sync_dirty_bitmap().
>
> Reported-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

As this function is only used on migration, should I integrate it on my
next push, or do you want to pull it, Paolo?

Later, Juan.


> ---
>  include/exec/ram_addr.h | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
> index 73d1bea8b6..cbc797ed05 100644
> --- a/include/exec/ram_addr.h
> +++ b/include/exec/ram_addr.h
> @@ -377,6 +377,7 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
>                                                 uint64_t *real_dirty_pages)
>  {
>      ram_addr_t addr;
> +    ram_addr_t offset = rb->offset;
>      unsigned long page = BIT_WORD(start >> TARGET_PAGE_BITS);
>      uint64_t num_dirty = 0;
>      unsigned long *dest = rb->bmap;
> @@ -386,8 +387,9 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
>          int k;
>          int nr = BITS_TO_LONGS(length >> TARGET_PAGE_BITS);
>          unsigned long * const *src;
> -        unsigned long idx = (page * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE;
> -        unsigned long offset = BIT_WORD((page * BITS_PER_LONG) %
> +        unsigned long word = BIT_WORD((start + offset) >> TARGET_PAGE_BITS);
> +        unsigned long idx = (word * BITS_PER_LONG) / DIRTY_MEMORY_BLOCK_SIZE;
> +        unsigned long offset = BIT_WORD((word * BITS_PER_LONG) %
>                                          DIRTY_MEMORY_BLOCK_SIZE);
>  
>          rcu_read_lock();
> @@ -416,7 +418,7 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
>      } else {
>          for (addr = 0; addr < length; addr += TARGET_PAGE_SIZE) {
>              if (cpu_physical_memory_test_and_clear_dirty(
> -                        start + addr,
> +                        start + addr + offset,
>                          TARGET_PAGE_SIZE,
>                          DIRTY_MEMORY_MIGRATION)) {
>                  *real_dirty_pages += 1;

  reply	other threads:[~2017-06-28  7:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28  2:43 [Qemu-devel] [PATCH] exec: fix access to ram_list.dirty_memory when sync dirty bitmap Haozhong Zhang
2017-06-28  7:30 ` Juan Quintela [this message]
2017-06-28  8:23   ` Paolo Bonzini
2017-06-28  9:09 ` Juan Quintela
2017-06-28 11:12   ` Haozhong Zhang
2017-06-28 11:32     ` Juan Quintela

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=87zics7eo6.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=haozhong.zhang@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.