qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).