Re: [Qemu-devel] [PATCH 10/27] Separate migration bitmap

[Avi Kivity]

On 07/24/2012 09:36 PM, Juan Quintela wrote:
> This patch creates a migration bitmap, which is periodically kept in
> sync with the qemu bitmap. A separate copy of the dirty bitmap for the
> migration limits the amount of concurrent access to the qemu bitmap
> from iothread and migration thread (which requires taking the big
> lock).
> 
> We use the qemu bitmap type.  We have to "undo" the dirty_pages
> counting optimization on the general dirty bitmap and do the counting
> optimization with the migration local bitmap.

I had different plans for this (and a stale and possibly smelly patchset
moving in that direction):

- move the dirty bytemap from a single global instance to
per-memory-region instances (in the MemoryRegion structure)
- convert it from a bytemap to either a per-client bitmap (client =
VGA/CODE/MIGRATION) or a variable bit-length bitfieldmap
- allocate the bitmaps or strangely named thingie above on demand, so
ordinarily you have nothing allocated and the framebuffer has a bitmap,
when you start migration you allocate a bitmap for memory and a
twobitmap for the framebuffer
- protect the whole thing using rcu

The patchset is stalled, mostly because it's very difficult to
disentangle the tcg stuff.  I don't think we should introduce a
dependency here, just something to keep in mind.


-- 
error compiling committee.c: too many arguments to function