Re: [Qemu-devel] [PATCH 32/38] kvm: use directly cpu_physical_memory_* api for tracking dirty pages

[Juan Quintela]

Peter Maydell <address@hidden> wrote:
> On 17 December 2013 15:26, Juan Quintela <address@hidden> wrote:
>> @@ -399,8 +401,9 @@ static int
>> kvm_get_dirty_pages_log_range(MemoryRegionSection *section,
>>                  page_number = (i * HOST_LONG_BITS + j) * hpratio;
>>                  addr1 = page_number * TARGET_PAGE_SIZE;
>>                  addr = section->offset_within_region + addr1;
>> -                memory_region_set_dirty(section->mr, addr,
>> -                                        TARGET_PAGE_SIZE * hpratio);
>> +                ram_addr = section->mr->ram_addr + addr;
>
> struct MemoryRegion says:
>     /* All fields are private - violators will be prosecuted */

good spot

> so fishing around in it for mr->ram_addr seems like a bad idea.
>
> Perhaps we could make memory_region_set_dirty() an inline
> function in memory.h instead?


But we already use it on two places on arch_init.c.  For instance:


static inline
ram_addr_t migration_bitmap_find_and_reset_dirty(MemoryRegion *mr,
                                                 ram_addr_t start)
{
    unsigned long base = mr->ram_addr >> TARGET_PAGE_BITS;


I tried to do the bitmap optimizations using memory_regions, and it got
me nowhere.  Basically we have:
- TCG: _knows_ how memory bitmap/regions/etc work (actually, never got
  ported to MemoryRegions)
- Migration:  We are weird, and we _know_ about ram_addr_t, and we only
  use it, we don't care about memory regions.

On this series we basicall went the other way around: we created
include/exec/ram_addr.h, and we made _both_ migration and memory_region
work on top of it.

Later, Juan.