Re: [Qemu-devel] An emulation failure occurs, if I hotplug vcpus immediately after the VM start

[David Hildenbrand]

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 <address@hidden> 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