From: Umesh Deshpande <udeshpan@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC PATCH v4 3/5] separate migration bitmap
Date: Sat, 20 Aug 2011 21:41:36 -0400 [thread overview]
Message-ID: <4E506250.6050405@redhat.com> (raw)
In-Reply-To: <4E4E5C3E.4010603@redhat.com>
On 08/19/2011 08:51 AM, Paolo Bonzini wrote:
> On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
>> @@ -2128,8 +2132,61 @@ void
>> cpu_physical_memory_reset_dirty(ram_addr_t start, ram_addr_t end,
>> start1, length);
>> }
>> }
>> +
>> }
>>
>> +void migration_bitmap_reset_dirty(ram_addr_t start, ram_addr_t end,
>> + int dirty_flags)
>> +{
>> + unsigned long length, start1;
>> +
>> + start &= TARGET_PAGE_MASK;
>> + end = TARGET_PAGE_ALIGN(end);
>> +
>> + length = end - start;
>> + if (length == 0) {
>> + return;
>> + }
>> +
>> + migration_bitmap_mask_dirty_range(start, length, dirty_flags);
>> +
>> + /* we modify the TLB cache so that the dirty bit will be set again
>> + when accessing the range */
>
> The comment does not apply here, and the code below can also be safely
> deleted.
>
>> + start1 = (unsigned long)qemu_safe_ram_ptr(start);
>> + /* Check that we don't span multiple blocks - this breaks the
>> + address comparisons below. */
>> + if ((unsigned long)qemu_safe_ram_ptr(end - 1) - start1
>> + != (end - 1) - start) {
>> + abort();
>> + }
>> +}
>> +
>> +void sync_migration_bitmap(ram_addr_t start, ram_addr_t end)
>> +{
>> + unsigned long length, len, i;
>> + ram_addr_t addr;
>> + start &= TARGET_PAGE_MASK;
>> + end = TARGET_PAGE_ALIGN(end);
>> +
>> + length = end - start;
>> + if (length == 0) {
>> + return;
>> + }
>> +
>> + len = length >> TARGET_PAGE_BITS;
>> + for (i = 0; i < len; i++) {
>> + addr = i << TARGET_PAGE_BITS;
>> + if (cpu_physical_memory_get_dirty(addr,
>> MIGRATION_DIRTY_FLAG)) {
>> + migration_bitmap_set_dirty(addr);
>> + cpu_physical_memory_reset_dirty(addr, addr +
>> TARGET_PAGE_SIZE,
>> + MIGRATION_DIRTY_FLAG);
>
> This should be run under the iothread lock. Pay attention to avoiding
> lock inversion: the I/O thread always takes the iothread lock outside
> and the ramlist lock within, so the migration thread must do the same.
>
> BTW, I think this code in the migration thread patch also needs the
> iothread lock:
>
>> if (stage < 0) {
>> cpu_physical_memory_set_dirty_tracking(0);
>> return 0;
>> }
>>
>> if (cpu_physical_sync_dirty_bitmap(0, TARGET_PHYS_ADDR_MAX) != 0) {
>> qemu_file_set_error(f);
>> return 0;
>> }
>>
Callers of above code snippets (sync_migration_bitmap etc.) are holding
the iothread mutex. It has been made sure that the original qemu dirty
bitmap is only accessed when holding the mutex.
>
> Finally, here:
>
>> /* Make sure all dirty bits are set */
>> QLIST_FOREACH(block, &ram_list.blocks, next) {
>> for (addr = block->offset; addr < block->offset +
>> block->length;
>> addr += TARGET_PAGE_SIZE) {
>> if (!migration_bitmap_get_dirty(addr,
>>
>> MIGRATION_DIRTY_FLAG)) {
>> migration_bitmap_set_dirty(addr);
>> }
>> }
>> }
>>
>
> ... you can skip the get_dirty operation since we are not interested
> in other flags than the migration flag for the migration-specific bitmap.
okay
Thanks
Umesh
next prev parent reply other threads:[~2011-08-21 1:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 12:51 [Qemu-devel] [RFC PATCH v4 3/5] separate migration bitmap Paolo Bonzini
2011-08-21 1:41 ` Umesh Deshpande [this message]
2011-08-22 8:30 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2011-08-17 3:56 [Qemu-devel] [RFC PATCH v4 0/5] Separate thread for VM migration Umesh Deshpande
2011-08-17 3:56 ` [Qemu-devel] [RFC PATCH v4 3/5] separate migration bitmap Umesh Deshpande
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=4E506250.6050405@redhat.com \
--to=udeshpan@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).