qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] An emulation failure occurs, if I hotplug vcpus immedia


From: 浙大邮箱
Subject: Re: [Qemu-devel] An emulation failure occurs, if I hotplug vcpus immediately after the VM start
Date: Fri, 8 Jun 2018 00:03:45 +0800

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]