All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Haozhong Zhang <haozhong.zhang@intel.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Xiao Guangrong <xiaoguangrong@tencent.com>
Subject: Re: [Qemu-devel] [PATCH v2] exec: fix access to ram_list.dirty_memory when sync dirty bitmap
Date: Wed, 28 Jun 2017 13:38:13 +0200	[thread overview]
Message-ID: <87k23w5om2.fsf@secure.mitica> (raw)
In-Reply-To: <2f01750b-8ab5-dd73-1d0e-2efc86f427ee@redhat.com> (Paolo Bonzini's message of "Wed, 28 Jun 2017 13:14:23 +0200")

Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 28/06/2017 10:37, Haozhong Zhang 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>
>> ---
>> Changes in v2:
>>  * Avoid shadowing variable 'offset'. (Paolo)
>> ---
>>  include/exec/ram_addr.h | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
>> index 73d1bea8b6..c04f4f67f6 100644
>> --- a/include/exec/ram_addr.h
>> +++ b/include/exec/ram_addr.h
>> @@ -386,8 +386,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 + rb->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();
>> @@ -414,9 +415,11 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
>>  
>>          rcu_read_unlock();
>>      } else {
>> +        ram_addr_t offset = rb->offset;
>> +
>>          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;
>> 
>
> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
>
> Juan, please take care of this yourself!  Thanks,

Already sent in a pull request 5 mins ago.
(so, it don't have your Ack :-)

Thanks, Juan.

      reply	other threads:[~2017-06-28 11:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28  8:37 [Qemu-devel] [PATCH v2] exec: fix access to ram_list.dirty_memory when sync dirty bitmap Haozhong Zhang
2017-06-28 10:04 ` Stefan Hajnoczi
2017-06-28 11:14 ` Paolo Bonzini
2017-06-28 11:38   ` Juan Quintela [this message]

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=87k23w5om2.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.