From: Gavin Shan <gshan@redhat.com>
To: Salil Mehta <salil.mehta@huawei.com>,
Shaoqin Huang <shahuang@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Cc: "oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"james.morse@arm.com" <james.morse@arm.com>,
Cornelia Huck <cohuck@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Salil Mehta <salil.mehta@opnsrc.net>
Subject: Re: [PATCH v1 0/5] target/arm: Handle psci calls in userspace
Date: Thu, 13 Jul 2023 10:27:57 +1000 [thread overview]
Message-ID: <7f524e2a-e773-4de0-09ed-b18eaec8ff16@redhat.com> (raw)
In-Reply-To: <539e6a25b89a45839de37fe92b27d0d3@huawei.com>
Hi Salil,
On 7/4/23 19:58, Salil Mehta wrote:
>
> Latest Qemu Prototype (Pre RFC V2) (Not in the final shape of the patches)
> https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v1-port11052023.dev-1
>
>
> should work against below kernel changes as confirmed by James,
>
> Latest Kernel Prototype (Pre RFC V2 = RFC V1 + Fixes)
> https://git.gitlab.arm.com/linux-arm/linux-jm.git virtual_cpu_hotplug/rfc/v2
>
I think it'd better to have the discussions through maillist. The threads and all
follow-up replies can be cached somewhere to avoid lost. Besides, other people may
be intrested in the same points and can join the discussion directly.
I got a chance to give the RFC patchsets some tests. Not all cases are working
as expected. I know the patchset is being polished. I'm summarize them as below:
(1) coredump is triggered when the topology is out of range. It's the issue we
discussed in private. Here I'm just recapping in case other people also blocked
by the issue.
(a) start VM with the following command lines
/home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \
-accel kvm -machine virt,gic-version=host,nvdimm=on -cpu host \
-smp cpus=1,maxcpus=2,sockets=1,clusters=1,cores=1,threads=2 \
-m 512M,slots=16,maxmem=64G \
-object memory-backend-ram,id=mem0,size=512M \
-numa node,nodeid=0,cpus=0-1,memdev=mem0 \
(b) hot add CPU whose topology is out of range
(qemu) device_add driver=host-arm-cpu,id=cpu1,core-id=1
It's actually caused by typos in hw/arm/virt.c::virt_cpu_pre_plug() where
'ms->possible_cpus->len' needs to be replaced with 'ms->smp.cores'. With this,
the hot-added CPU object will be rejected.
(2) I don't think TCG has been tested since it seems not working at all.
(a) start VM with the following command lines
/home/gshan/sandbox/src/qemu/main/build/qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu max -m 1024 \
-smp maxcpus=2,cpus=1,sockets=1,clusters=1,cores=1,threads=2 \
(b) failure while hot-adding CPU
(qemu) device_add driver=max-arm-cpu,id=cpu1,thread-id=1
Error: cpu(id1=0:0:0:1) with arch-id 1 exists
The error message is printed by hw/arm/virt.c::virt_cpu_pre_plug() where the
specific CPU has been presented. For KVM case, the disabled CPUs are detached
from 'ms->possible_cpu->cpus[1].cpu' and destroyed. I think we need to do similar
thing for TCG case in hw/arm/virt.c::virt_cpu_post_init(). I'm able to add CPU
with the following hunk of changes.
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -2122,6 +2122,18 @@ static void virt_cpu_post_init(VirtMachineState *vms, MemoryRegion *sysmem)
exit(1);
}
}
+
+#if 1
+ for (n = 0; n < possible_cpus->len; n++) {
+ cpu = qemu_get_possible_cpu(n);
+ if (!qemu_enabled_cpu(cpu)) {
+ CPUArchId *cpu_slot;
+ cpu_slot = virt_find_cpu_slot(ms, cpu->cpu_index);
+ cpu_slot->cpu = NULL;
+ object_unref(OBJECT(cpu));
+ }
+ }
+#endif
}
}
(3) Assertion on following the sequence of hot-add, hot-remove and hot-add when TCG mode is enabled.
(a) Include the hack from (2) and start VM with the following command lines
/home/gshan/sandbox/src/qemu/main/build/qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu max -m 1024 \
-smp maxcpus=2,cpus=1,sockets=1,clusters=1,cores=1,threads=2 \
(b) assertion on the sequence of hot-add, hot-remove and hot-add
(qemu) device_add driver=max-arm-cpu,id=cpu1,thread-id=1
(qemu) device_del cpu1
(qemu) device_add driver=max-arm-cpu,id=cpu1,thread-id=1
**
ERROR:../tcg/tcg.c:669:tcg_register_thread: assertion failed: (n < tcg_max_ctxs)
Bail out! ERROR:../tcg/tcg.c:669:tcg_register_thread: assertion failed: (n < tcg_max_ctxs)
Aborted (core dumped)
I'm not sure if x86 has similar issue. It seems the management for TCG contexts, corresponding
to variable @tcg_max_ctxs and @tcg_ctxs need some improvements for better TCG context registration
and unregistration to accomodate CPU hotplug.
Apart from what have been found in the tests, I've started to look into the code changes. I may
reply with more specific comments. However, it would be ideal to comment on the specific changes
after the patchset is posted for review. Salil, the plan may have been mentioned by you somewhere.
As I understood, the QEMU patchset will be posted after James's RFCv2 kernel series is posted.
Please let me know if my understanding is correct. Again, thanks for your efforts to make vCPU
hotplug to be supported :)
Thanks,
Gavin
prev parent reply other threads:[~2023-07-13 0:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-26 6:49 [PATCH v1 0/5] target/arm: Handle psci calls in userspace Shaoqin Huang
2023-06-26 6:49 ` [PATCH v1 1/5] linux-headers: Update to v6.4-rc7 Shaoqin Huang
2023-06-26 6:49 ` [PATCH v1 2/5] linux-headers: Import arm-smccc.h from Linux v6.4-rc7 Shaoqin Huang
2023-07-04 9:05 ` Cornelia Huck
2023-06-26 6:49 ` [PATCH v1 3/5] target/arm: make psci call can be used by kvm Shaoqin Huang
2023-06-26 6:49 ` [PATCH v1 4/5] arm/kvm: add skeleton implementation for userspace SMCCC call handling Shaoqin Huang
2023-07-04 9:17 ` Cornelia Huck
2023-06-26 6:49 ` [PATCH v1 5/5] arm/kvm: add support for userspace psci calls handling Shaoqin Huang
2023-06-26 13:42 ` [PATCH v1 0/5] target/arm: Handle psci calls in userspace Salil Mehta via
2023-06-27 2:34 ` Shaoqin Huang
2023-07-04 9:58 ` Salil Mehta via
2023-07-13 0:27 ` Gavin Shan [this message]
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=7f524e2a-e773-4de0-09ed-b18eaec8ff16@redhat.com \
--to=gshan@redhat.com \
--cc=cohuck@redhat.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=salil.mehta@huawei.com \
--cc=salil.mehta@opnsrc.net \
--cc=shahuang@redhat.com \
/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).