> 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. Thanks Salil.
