Re: [PATCH v2 04/10] Introduce the CPU address space destruction function

[lixianglai]

Hi Salil Mehta:
> > From: Salil Mehta
> > Sent: Tuesday, September 26, 2023 12:21 PM
> > To: 'David Hildenbrand' <david@redhat.com>; lixianglai
> > <lixianglai@loongson.cn>; qemu-devel@nongnu.org
> > Cc: Salil Mehta <salil.mehta@opnsrc.net>; Xiaojuan Yang
> > <yangxiaojuan@loongson.cn>; Song Gao <gaosong@loongson.cn>; Michael S.
> > Tsirkin <mst@redhat.com>; Igor Mammedov <imammedo@redhat.com>; Ani Sinha
> > <anisinha@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard
> > Henderson <richard.henderson@linaro.org>; Eduardo Habkost
> > <eduardo@habkost.net>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> > Philippe Mathieu-Daudé <philmd@linaro.org>; wangyanan (Y)
> > <wangyanan55@huawei.com>; Daniel P. Berrangé <berrange@redhat.com>; Peter
> > Xu <peterx@redhat.com>; Bibo Mao <maobibo@loongson.cn>
> > Subject: RE: [PATCH v2 04/10] Introduce the CPU address space destruction
> > function
> >
> > Hi David,
> >
> > > From: David Hildenbrand <david@redhat.com>
> > > Sent: Friday, September 15, 2023 9:07 AM
> > > To: lixianglai <lixianglai@loongson.cn>; qemu-devel@nongnu.org; Salil
> > Mehta
> > > <salil.mehta@huawei.com>
> > > Cc: Salil Mehta <salil.mehta@opnsrc.net>; Xiaojuan Yang
> > > <yangxiaojuan@loongson.cn>; Song Gao <gaosong@loongson.cn>; Michael S.
> > > Tsirkin <mst@redhat.com>; Igor Mammedov <imammedo@redhat.com>; Ani Sinha
> > > <anisinha@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; Richard
> > > Henderson <richard.henderson@linaro.org>; Eduardo Habkost
> > > <eduardo@habkost.net>; Marcel Apfelbaum <marcel.apfelbaum@gmail.com>;
> > > Philippe Mathieu-Daudé <philmd@linaro.org>; wangyanan (Y)
> > > <wangyanan55@huawei.com>; Daniel P. Berrangé <berrange@redhat.com>; Peter
> > > Xu <peterx@redhat.com>; Bibo Mao <maobibo@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.mehta@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?

That's Ok for me.

Thanks,

Xianglai.


> Many thanks
> Salil