Avi Kivity <a...@redhat.com> wrote: > 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.
I tried something like that myself (before your memory regions work). And got stuck on the same problem: - for migration, I always had a ramblock handy - for vga the same (well, I am not sure for the sparc ones, I think they were weird on that respect) - for TCG, there is none around that I can find. I guess it is there somewhere, but not in any obvious part. So, to fix TCG, we need a TCG guru, and probably change the access parters somehow :p Later, Juan.
