> From: David Hildenbrand <da...@redhat.com> > Sent: Tuesday, September 26, 2023 1:37 PM > To: Salil Mehta <salil.me...@huawei.com>; lixianglai > <lixiang...@loongson.cn>; qemu-devel@nongnu.org > Cc: Salil Mehta <salil.me...@opnsrc.net>; Xiaojuan Yang > <yangxiaoj...@loongson.cn>; Song Gao <gaos...@loongson.cn>; Michael S. > Tsirkin <m...@redhat.com>; Igor Mammedov <imamm...@redhat.com>; Ani Sinha > <anisi...@redhat.com>; Paolo Bonzini <pbonz...@redhat.com>; Richard > Henderson <richard.hender...@linaro.org>; Eduardo Habkost > <edua...@habkost.net>; Marcel Apfelbaum <marcel.apfelb...@gmail.com>; > Philippe Mathieu-Daudé <phi...@linaro.org>; wangyanan (Y) > <wangyana...@huawei.com>; Daniel P. Berrangé <berra...@redhat.com>; Peter > Xu <pet...@redhat.com>; Bibo Mao <maob...@loongson.cn> > Subject: Re: [PATCH v2 04/10] Introduce the CPU address space destruction > function > > On 26.09.23 14:32, Salil Mehta wrote: > >> From: David Hildenbrand <da...@redhat.com> > >> Sent: Tuesday, September 26, 2023 1:24 PM > >> > >> On 26.09.23 13:55, Salil Mehta wrote: > >>>> From: Salil Mehta > >>>> Sent: Tuesday, September 26, 2023 12:21 PM > >>>> To: 'David Hildenbrand' <da...@redhat.com>; lixianglai > >>>> <lixiang...@loongson.cn>; qemu-devel@nongnu.org > >>>> Cc: Salil Mehta <salil.me...@opnsrc.net>; Xiaojuan Yang > >>>> <yangxiaoj...@loongson.cn>; Song Gao <gaos...@loongson.cn>; Michael S. > >>>> Tsirkin <m...@redhat.com>; Igor Mammedov <imamm...@redhat.com>; Ani > Sinha > >>>> <anisi...@redhat.com>; Paolo Bonzini <pbonz...@redhat.com>; Richard > >>>> Henderson <richard.hender...@linaro.org>; Eduardo Habkost > >>>> <edua...@habkost.net>; Marcel Apfelbaum <marcel.apfelb...@gmail.com>; > >>>> Philippe Mathieu-Daudé <phi...@linaro.org>; wangyanan (Y) > >>>> <wangyana...@huawei.com>; Daniel P. Berrangé <berra...@redhat.com>; > >> Peter > >>>> Xu <pet...@redhat.com>; Bibo Mao <maob...@loongson.cn> > >>>> Subject: RE: [PATCH v2 04/10] Introduce the CPU address space > >> destruction > >>>> function > >>>> > >>>> Hi David, > >>>> > >>>>> From: David Hildenbrand <da...@redhat.com> > >>>>> Sent: Friday, September 15, 2023 9:07 AM > >>>>> To: lixianglai <lixiang...@loongson.cn>; qemu-devel@nongnu.org; Salil > >>>> Mehta > >>>>> <salil.me...@huawei.com> > >>>>> Cc: Salil Mehta <salil.me...@opnsrc.net>; Xiaojuan Yang > >>>>> <yangxiaoj...@loongson.cn>; Song Gao <gaos...@loongson.cn>; Michael > S. > >>>>> Tsirkin <m...@redhat.com>; Igor Mammedov <imamm...@redhat.com>; Ani > >> Sinha > >>>>> <anisi...@redhat.com>; Paolo Bonzini <pbonz...@redhat.com>; Richard > >>>>> Henderson <richard.hender...@linaro.org>; Eduardo Habkost > >>>>> <edua...@habkost.net>; Marcel Apfelbaum <marcel.apfelb...@gmail.com>; > >>>>> Philippe Mathieu-Daudé <phi...@linaro.org>; wangyanan (Y) > >>>>> <wangyana...@huawei.com>; Daniel P. Berrangé <berra...@redhat.com>; > >> Peter > >>>>> Xu <pet...@redhat.com>; Bibo Mao <maob...@loongson.cn> > >>>>> Subject: Re: [PATCH v2 04/10] Introduce the CPU address space > >> destruction > >>>>> function > >>>>> > >>>>> On 15.09.23 04:53, lixianglai wrote: > >>>>>> Hi David Hildenbrand: > >>>>>> > >>>>>>> > >>>>>>> Hi David Hildenbrand: > >>>>>>>> On 14.09.23 15:00, lixianglai wrote: > >>>>>>>>> Hi David: > >>>>>>>> > >>>>>>>> Hi! > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> On 12.09.23 04:11, xianglai li wrote: > >>>>>>>>>>> Introduce new function to destroy CPU address space resources > >>>>>>>>>>> for cpu hot-(un)plug. > >>>>>>>>>>> > >>>>>>>>>> How do other archs handle that? Or how are they able to get away > >>>>>>>>>> without destroying? > >>>>>>>>>> > >>>>>>>>> They do not remove the cpu address space, taking the X86 > >>>>>>>>> architecture as > >>>>>>>>> an example: > >>>>>>>>> > >>>>>>>>> 1.Start the x86 VM: > >>>>>>>>> > >>>>>>>>> ./qemu-system-x86_64 \ > >>>>>>>>> -machine q35 \ > >>>>>>>>> -cpu Broadwell-IBRS \ > >>>>>>>>> -smp 1,maxcpus=100,sockets=100,cores=1,threads=1 \ > >>>>>>>>> -m 4G \ > >>>>>>>>> -drive file=~/anolis-8.8.qcow2 \ > >>>>>>>>> -serial stdio \ > >>>>>>>>> -monitor telnet:localhost:4498,server,nowait \ > >>>>>>>>> -nographic > >>>>>>>>> > >>>>>>>>> 2.Connect the qemu monitor > >>>>>>>>> > >>>>>>>>> telnet 127.0.0.1 4498 > >>>>>>>>> > >>>>>>>>> info mtree > >>>>>>>>> > >>>>>>>>> address-space: cpu-memory-0 > >>>>>>>>> address-space: memory > >>>>>>>>> 0000000000000000-ffffffffffffffff (prio 0, i/o): system > >>>>>>>>> 0000000000000000-000000007fffffff (prio 0, ram): alias > >>>>>>>>> ram-below-4g > >>>>>>>>> @pc.ram 0000000000000000-000000007fffffff > >>>>>>>>> 0000000000000000-ffffffffffffffff (prio -1, i/o): pci > >>>>>>>>> 00000000000a0000-00000000000bffff (prio 1, i/o): vga- > >> lowmem > >>>>>>>>> > >>>>>>>>> 3.Perform cpu hot swap int qemu monitor > >>>>>>>>> > >>>>>>>>> device_add > >>>>>>>>> Broadwell-IBRS-x86_64-cpu,socket-id=1,core-id=0,thread- > id=0,id=cpu1 > >>>>>>>>> device_del cpu1 > >>>>>>>>> > >>>>>>>> > >>>>>>>> Hm, doesn't seem to work for me on upstream QEMU for some reason: > >>>>>>>> "Error: acpi: device unplug request for not supported device type: > >>>>>>>> Broadwell-IBRS-x86_64-cpu" > >>>>>>> > >>>>>> First I use qemu tcg, and then the cpu needs to be removed after the > >>>>>> operating system is booted. > >>>>> > >>>>> Ah, the last thing is the important bit. I can reproduce this with > KVM > >>>>> easily. > >>>>> > >>>>> Doing it a couple of times > >>>>> > >>>>> address-space: cpu-memory-0 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> address-space: cpu-memory-1 > >>>>> > >>>>> Looks like a resource/memory leak. > >>>> > >>>> Yes, there was. Thanks for identifying it. I have fixed in the > >>>> latest RFC V2. Please check here: > >>>> > >>>> https://lore.kernel.org/qemu-devel/20230926100436.28284-1- > >>>> salil.me...@huawei.com/T/#m5f5ae40b091d69d01012880d7500d96874a9d39c > >>>> > >>>> I have tested and AddressSpace comes and goes away cleanly > >>>> on CPU hot(un)plug action. > >>> > >>> Hi David/Xianglai, > >>> Are you okay if I put Reported-by and give reference to this > >>> conversation? > >> > >> Yes. And ideally, send the fixes separately from the other arm patches. > > > > ARM Virtual CPU Hotplug support patches are still under review. > > The other architectures (as shown, x86 is affected) can be fixed > independent of that support.
Yes, they can be and the TCG as well. Unrealize part of TCG is broken even on ARM. Need some way to cleanly unassign Translation blocks from the Region trees. That’s a pending work at our end. But you are more than welcome to help and contribute in that as well. Also, I can help to contribute, if required. Many thanks Salil.
