> 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? Many thanks Salil
