On 07.06.2018 14:36, Paolo Bonzini wrote:
> On 07/06/2018 13:36, David Hildenbrand wrote:
>>> The dirty bitmap would be synced in kvm_region_del (so it's not true
>>> that kvm_region_del would disappear, but almost :)).
>> I was rather concerned when doing a KVM_SET_USER_MEMORY_REGIONS while
>> some (already present) memory region is performing dirty tracking and
>> therefore has a dirty_bitmap pointer assigned.
>>
>> As we have to expect that all different kinds of parameters can change
>> (e.g. the size of a slot as I pointed out), the old bitmap cannot be
>> reused. At least not atomically - we could create a new one and the
>> simply or the old content.
>>
>> Well, we could make that dirty tracking a special case ("all dirty
>> tracking data will be lost in case doing a KVM_SET_USER_MEMORY_REGIONS"
>> - but this again could lead to races (if the bitmap sync happens before
>> KVM_SET_USER_MEMORY_REGIONS)). It's tricky to get it right :)
>
> At the point where QEMU calls region_del, the guest is not supposed to
> access the region anymore, so it's okay to do the final sync there. The
> same race exists now already.
The point is that KVM_SET_USER_MEMORY_REGIONS is the big hammer, not the
fine grained region_add/region_del. All regions are suddenly involved.
So we have to handle dirty_bitmaps somehow.
But I agree that those that would actually change
(split/resized/whatever) should not be currently dirty tracked (or at if
they are, they should be able to live with the possible race).
Devil is in the detail :)
>
> Paolo
>
>>> The rmap is more interesting. Perhaps it can be just rebuilt on every
>>> KVM_SET_USER_MEMORY_REGIONS call.
>
--
Thanks,
David / dhildenb
