From: Juan Quintela <quintela@redhat.com>
To: qemu-devel@nongnu.org
Cc: 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 13:32:14 +0200 [thread overview]
Message-ID: <87wp7w5ow1.fsf@secure.mitica> (raw)
In-Reply-To: <20170628111214.4ycvgzy4a53gt4tl@hz-desktop> (Haozhong Zhang's message of "Wed, 28 Jun 2017 19:12:14 +0800")
Haozhong Zhang <haozhong.zhang@intel.com> wrote:
> On 06/28/17 11:09 +0200, Juan Quintela wrote:
>> 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>
>>
>>
>> Hi
>>
>> I need to add this patch to make it compile for me with all
>> architectures enabled.
>>
>> I am adding that to you patch, are you ok?
>>
>
> Remind me why your following patch is related to mine? My patch does
> not touch any vmstate.
O:-)
Because sometimes I got a bit sloppy.
Sorry.
Later, Juan.
prev parent reply other threads:[~2017-06-28 11:32 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
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 [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=87wp7w5ow1.fsf@secure.mitica \
--to=quintela@redhat.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.