On 2011-07-21 15:43, Avi Kivity wrote:
>>>> @@ -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.
Then the logic indeed belongs to kvm-all.c, not memory.c.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
