Re: [Qemu-devel] [PATCH 42/51] ram: Pass RAMBlock to bitmap_sync

[Juan Quintela]

"Dr. David Alan Gilbert" <address@hidden> wrote:
> * Juan Quintela (address@hidden) wrote:
>> "Dr. David Alan Gilbert" <address@hidden> wrote:
>> > * Juan Quintela (address@hidden) wrote:
>> >> We change the meaning of start to be the offset from the beggining of
>> >> the block.
>> >
>> > s/beggining/beginning/
>> >
>> > Why do this?
>> > We have:
>> >    migration_bitmap_sync (all blocks)
>> >    migration_bitmap_sync_range - called per block
>> >    cpu_physical_memory_sync_dirty_bitmap
>> >
>> > Why keep migration_bitmap_sync_range having start/length as well
>> > as the block
>> > if you could just rename it to migration_bitmap_sync_block and
>> > just give it the rb?
>> > And since cpu_physical_memory_clear_dirty_range is lower level,
>> > why give it
>> > the rb?
>> 
>> I did it on the previous series, then I remembered that I was not going
>> to be able to sync only part of the range, as I will want in the future.
>> 
>> If you preffer as an intermediate meassure to just move to blocks, I can
>> do, but change is really small and not sure if it makes sense.
>
> OK then, but just comment it to say you want to.
> I'm still not sure if cpu_physical_memory_clear_dirty_range should
> have the RB;
> it feels that it's lower level, kvm stuff rather than things that know
> about RAMBlocks.

Bitmap is going to be there in the following patch.  Not a lot that we
can be done about that, no?

Right now we have:

- absolute address
- RAMblock
- byte offset inside block
- byte offset of ramblock
- Whole bitmaps (Migration, code and vga)
- migration bitmaps

This rseries move the migration bitmap inside the RAMBlock.  And we have
the RAMBlock in the caller.  We could search for it there, but looks
very inefficient.

I am trying to change all the code to use:

RAMblock pointer + target page offset inside ramblock

So we need to do a lot less calculations.

Later, Juan.