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

[Salil Mehta via <qemu-devel@nongnu.org>]

> 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?

Many thanks
Salil