From: David Hildenbrand <david@redhat.com>
To: 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>,
"Yanan Wang" <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
Date: Thu, 14 Sep 2023 15:26:37 +0200 [thread overview]
Message-ID: <dd2b9190-c748-0ae2-b9de-8842e6e758e2@redhat.com> (raw)
In-Reply-To: <20eb8316-22a2-c812-7172-6bd9016877cc@loongson.cn>
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"
What happens if you re-add that CPU? Will we reuse the previous address
space?
> info mtree
>
> address-space: cpu-memory-0
> address-space: cpu-memory-1
> 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
>
>
> From the above test, you can see whether the address space of cpu1 is
> residual after a cpu hot swap, and whether it is reasonable?
Probably we should teach other archs to destroy that address space as well.
Can we do that from the core, instead of having to do that in each CPU
unrealize function?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-09-14 13:27 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 2:11 [PATCH v2 00/10] Adds CPU hot-plug support to Loongarch xianglai li
2023-09-12 2:11 ` [PATCH v2 01/10] Update ACPI GED framework to support vcpu hot-(un)plug xianglai li
2023-09-12 2:11 ` [PATCH v2 02/10] Update CPUs AML with cpu-(ctrl)dev change xianglai li
2023-09-12 2:11 ` [PATCH v2 03/10] make qdev_disconnect_gpio_out_named() public xianglai li
2023-09-12 8:10 ` Philippe Mathieu-Daudé
2023-09-15 7:00 ` lixianglai
2023-09-12 2:11 ` [PATCH v2 04/10] Introduce the CPU address space destruction function xianglai li
2023-09-12 7:00 ` David Hildenbrand
2023-09-14 13:00 ` lixianglai
2023-09-14 13:26 ` David Hildenbrand [this message]
2023-09-15 2:48 ` lixianglai
2023-09-15 2:53 ` lixianglai
2023-09-15 8:07 ` David Hildenbrand
2023-09-15 9:54 ` lixianglai
2023-09-15 14:19 ` Philippe Mathieu-Daudé
2023-09-15 15:22 ` David Hildenbrand
2023-09-26 11:25 ` Salil Mehta via
2023-09-26 11:21 ` Salil Mehta via
2023-09-26 11:55 ` Salil Mehta via
2023-09-26 12:23 ` David Hildenbrand
2023-09-26 12:32 ` Salil Mehta via
2023-09-26 12:37 ` David Hildenbrand
2023-09-26 12:44 ` Salil Mehta via
2023-09-26 12:52 ` David Hildenbrand
2023-09-27 2:16 ` lixianglai
2023-09-26 11:11 ` Salil Mehta via
2023-09-26 11:06 ` Salil Mehta via
2023-09-26 11:03 ` Salil Mehta via
2023-09-12 2:11 ` [PATCH v2 05/10] Added CPU topology support for Loongarch xianglai li
2023-09-12 2:11 ` [PATCH v2 06/10] Optimize loongarch_irq_init function implementation xianglai li
2023-09-12 2:11 ` [PATCH v2 07/10] Add basic CPU hot-(un)plug support for Loongarch xianglai li
2023-09-12 2:11 ` [PATCH v2 08/10] Add support of *unrealize* for Loongarch cpu xianglai li
2023-09-12 2:11 ` [PATCH v2 09/10] Add generic event device for Loongarch xianglai li
2023-09-12 2:11 ` [PATCH v2 10/10] Update the ACPI table for the Loongarch CPU xianglai li
2023-09-12 9:08 ` [PATCH v2 00/10] Adds CPU hot-plug support to Loongarch Salil Mehta via
2023-09-13 3:52 ` lixianglai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd2b9190-c748-0ae2-b9de-8842e6e758e2@redhat.com \
--to=david@redhat.com \
--cc=anisinha@redhat.com \
--cc=berrange@redhat.com \
--cc=eduardo@habkost.net \
--cc=gaosong@loongson.cn \
--cc=imammedo@redhat.com \
--cc=lixianglai@loongson.cn \
--cc=maobibo@loongson.cn \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=salil.mehta@opnsrc.net \
--cc=wangyanan55@huawei.com \
--cc=yangxiaojuan@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).