From: David Hildenbrand <david@redhat.com> To: 浙大邮箱 <linzc@zju.edu.cn> Cc: "Huangweidong \(C\)" <weidong.huang@huawei.com>, Zhanghailiang <zhang.zhanghailiang@huawei.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, xuyandong <xuyandong2@huawei.com>, "wangxin \(U\)" <wangxinxin.wang@huawei.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, lidonglin <lidonglin@huawei.com>, "Gonglei \(Arei\)" <arei.gonglei@huawei.com>, Igor Mammedov <imammedo@redhat.com>, Paolo Bonzini <pbonzini@redhat.com> Subject: Re: An emulation failure occurs, if I hotplug vcpus immediately after the VM start Date: Mon, 11 Jun 2018 12:44:20 +0200 [thread overview] Message-ID: <679ab02f-b110-c80a-c99e-1301b7fa1725@redhat.com> (raw) In-Reply-To: <AE460DFB-87F8-45A3-A007-E59C3B23BB67@zju.edu.cn> 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@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com> To: 浙大邮箱 <linzc@zju.edu.cn> Cc: Paolo Bonzini <pbonzini@redhat.com>, "Gonglei (Arei)" <arei.gonglei@huawei.com>, Igor Mammedov <imammedo@redhat.com>, xuyandong <xuyandong2@huawei.com>, Zhanghailiang <zhang.zhanghailiang@huawei.com>, "wangxin (U)" <wangxinxin.wang@huawei.com>, lidonglin <lidonglin@huawei.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Huangweidong (C)" <weidong.huang@huawei.com> Subject: Re: [Qemu-devel] An emulation failure occurs, if I hotplug vcpus immediately after the VM start Date: Mon, 11 Jun 2018 12:44:20 +0200 [thread overview] Message-ID: <679ab02f-b110-c80a-c99e-1301b7fa1725@redhat.com> (raw) In-Reply-To: <AE460DFB-87F8-45A3-A007-E59C3B23BB67@zju.edu.cn> 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@redhat.com> 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
next prev parent reply other threads:[~2018-06-11 10:44 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-01 8:17 An emulation failure occurs, if I hotplug vcpus immediately after the VM start xuyandong 2018-06-01 8:17 ` [Qemu-devel] " xuyandong 2018-06-01 10:23 ` Igor Mammedov 2018-06-01 10:23 ` [Qemu-devel] " Igor Mammedov 2018-06-06 13:28 ` Gonglei (Arei) 2018-06-06 13:28 ` [Qemu-devel] " Gonglei (Arei) 2018-06-06 13:57 ` Paolo Bonzini 2018-06-06 13:57 ` [Qemu-devel] " Paolo Bonzini 2018-06-06 14:18 ` xuyandong 2018-06-06 14:18 ` [Qemu-devel] " xuyandong 2018-06-06 14:23 ` Paolo Bonzini 2018-06-06 14:23 ` [Qemu-devel] " Paolo Bonzini 2018-06-07 10:37 ` David Hildenbrand 2018-06-07 10:37 ` [Qemu-devel] " David Hildenbrand 2018-06-07 11:02 ` Paolo Bonzini 2018-06-07 11:02 ` [Qemu-devel] " Paolo Bonzini 2018-06-07 11:36 ` David Hildenbrand 2018-06-07 11:36 ` [Qemu-devel] " David Hildenbrand 2018-06-07 12:36 ` Paolo Bonzini 2018-06-07 12:36 ` [Qemu-devel] " Paolo Bonzini 2018-06-07 12:55 ` David Hildenbrand 2018-06-07 12:55 ` [Qemu-devel] " David Hildenbrand 2018-06-07 16:03 ` 浙大邮箱 2018-06-07 16:03 ` [Qemu-devel] " 浙大邮箱 2018-06-11 10:44 ` David Hildenbrand [this message] 2018-06-11 10:44 ` David Hildenbrand 2018-06-11 12:25 ` Gonglei (Arei) 2018-06-11 12:25 ` [Qemu-devel] " Gonglei (Arei) 2018-06-11 12:36 ` David Hildenbrand 2018-06-11 12:36 ` [Qemu-devel] " David Hildenbrand 2018-06-11 13:25 ` Gonglei (Arei) 2018-06-11 13:25 ` [Qemu-devel] " Gonglei (Arei) 2018-06-07 10:39 ` David Hildenbrand 2018-06-07 10:39 ` [Qemu-devel] " David Hildenbrand 2018-06-07 11:13 ` Gonglei (Arei) 2018-06-07 11:13 ` [Qemu-devel] " Gonglei (Arei) 2018-06-07 11:43 ` David Hildenbrand 2018-06-07 11:43 ` [Qemu-devel] " David Hildenbrand
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=679ab02f-b110-c80a-c99e-1301b7fa1725@redhat.com \ --to=david@redhat.com \ --cc=arei.gonglei@huawei.com \ --cc=imammedo@redhat.com \ --cc=kvm@vger.kernel.org \ --cc=lidonglin@huawei.com \ --cc=linzc@zju.edu.cn \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=wangxinxin.wang@huawei.com \ --cc=weidong.huang@huawei.com \ --cc=xuyandong2@huawei.com \ --cc=zhang.zhanghailiang@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.