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
