On 07.06.2018 18:03, 浙大邮箱 wrote:
> Hi，all
> I still have a question after reading your discussion: Will seabios detect the change of address space even if we add_region and del_region automatically? I guess that seabios may not take this change into consideration.
Hi,
We would just change the way how KVM memory slots are updated. This is
right now not atomic, but would be later on. It should not have any
other effect.
Thanks
>
> Looking forward to your replies,
> Thanks
>
>>> On Jun 7, 2018, at 20:55, David Hildenbrand <david@xxxxxxxxxx> wrote:
>>>
>>> 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
>
--
Thanks,
David / dhildenb
