On 07/21/2011 04:38 PM, Jan Kiszka wrote:
On 2011-07-21 10:37, Avi Kivity wrote: > On 07/21/2011 12:43 AM, Jan Kiszka wrote: >> On 2011-07-20 19:43, Avi Kivity wrote: >> > On 07/20/2011 08:41 PM, Jan Kiszka wrote: >> >> On 2011-07-20 18:49, Avi Kivity wrote: >> >> > New in this version: >> >> > - more mindless conversions; I believe there are no longer any >> >> destructive >> >> > operations in the tree (IO_MEM_UNASSIGNED) >> >> > - fix memory map generation bug (patch 13) >> >> > - proper 440FX PAM/SMRAM and PCI holes >> >> > >> >> >> >> This on top fixes standard VGA dirty logging: >> > >> > Both work for me without any patches. >> >> Impossible! ;) >> >> VGA frame buffer cannot work as no one enabled dirty logging for that >> range so far. Try -vga std with vga=0x314 in the guest. >> > > Right, actually booting into X showed that. But I don't understand how > it worked before - my patches only change how vga_start_dirty_log() is > implemented, not when/where it is called. To answer this question as well: You dropped all the vga_start_dirty_log originally performed during PCI mapping.
Ah, I see it now, in vga_map(). Thanks.
>> @@ -1093,9 +1093,26 @@ void >> memory_region_add_subregion_overlap(MemoryRegion *mr, >> void memory_region_del_subregion(MemoryRegion *mr, >> MemoryRegion *subregion) >> { >> + MemoryRegion *target_region; >> + ram_addr_t base, offs; >> + >> assert(subregion->parent == mr); >> subregion->parent = NULL; >> QTAILQ_REMOVE(&mr->subregions, subregion, subregions_link); >> + >> + if (subregion->alias) { >> + base = subregion->alias_offset; >> + target_region = subregion->alias; >> + } else { >> + base = 0; >> + target_region = subregion; >> + } >> + if (target_region->dirty_log_mask) { >> + for (offs = 0; offs< subregion->size; offs += >> TARGET_PAGE_SIZE) { >> + memory_region_set_dirty(target_region, base + offs); >> + } >> + } >> + > > The subregion may be partially or fully obstructed. This needs to be > done at the FlatRange level (as_memory_range_del(), most likely). Makes some sense. I even wonder if this isn't a KVM deficit and should be handled there when a logged region is unmapped.
What do you mean? There is a known issue with kvm here, this is a just workaround.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html