On 07.06.2018 13:02, Paolo Bonzini wrote:
> On 07/06/2018 12:37, David Hildenbrand wrote:
>>
>> I have a related requirement, which would be to atomically grow a
>> memory regions. So instead of region_del(old)+region_add(new), I would
>> have to do it in one shot (atomically).
>>
>> AFAICS an atomic replace of the memory map would work for this, too.
>> However I am not sure how we want to handle all kinds of tracking data
>> that is connected to e.g. x86 memory slots (e.g. rmap, dirty bitmap ...).
>
> 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 :)
>
> The rmap is more interesting. Perhaps it can be just rebuilt on every
> KVM_SET_USER_MEMORY_REGIONS call.
>
> Paolo
>
--
Thanks,
David / dhildenb
