Hi Andrew: Thanks for your reply. It 's fine for me if you are still tracking the thread. And I can help to test if needed ^_^. > -----Original Message----- > From: Andrew Jones [mailto:drjones@redhat.com] > Sent: Tuesday, December 10, 2019 6:13 PM > To: Zengtao (B) > Cc: qemu-devel@nongnu.org; qemu-arm@nongnu.org; wei@redhat.com; > peter.maydell@linaro.org; eric.auger@redhat.com; > imammedo@redhat.com; xuwei (O); huangdaode > Subject: Re: [Qemu-devel] [RFC PATCH 0/6] hw/arm/virt: Introduce cpu > topology support > > On Mon, Dec 09, 2019 at 02:14:09AM +0000, Zengtao (B) wrote: > > Hi Andrew: > > > > Any update for this patch series? I have met the same issue, and if the > > topology guessed by linux MPIDR conflicts with qemu specified numa, it > > will failed to boot (sched domain initialization will fall into deadloop). > > Hi Zeng, > > This has been on my TODO list a long time, but it keeps getting preempted. > We need to start by giving userspace control over the MPIDRs, including > when KVM is in use. The earliest I can return to this will be mid/late > January. If you'd like to jump in on it now, then feel free. > > Thanks, > drew > > > > > Thanks. > > > > > -----Original Message----- > > > From: Qemu-devel > > > > [mailto:qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.or > > > g] On Behalf Of Andrew Jones > > > Sent: Thursday, July 05, 2018 4:49 AM > > > To: qemu-devel@nongnu.org; qemu-arm@nongnu.org > > > Cc: wei@redhat.com; peter.maydell@linaro.org; > eric.auger@redhat.com; > > > imammedo@redhat.com > > > Subject: [Qemu-devel] [RFC PATCH 0/6] hw/arm/virt: Introduce cpu > > > topology support > > > > > > This series provides support for booting mach-virt machines with > > > non-flat cpu topology, i.e. enabling the extended options of the > > > '-smp' command line parameter (sockets,cores,threads). Both DT and > > > ACPI description generators are added. We only apply the new feature > > > to 3.1 and later machine types, as the change is guest visible, even > > > when no command line change is made. This is because the basic > > > '-smp <N>' parameter makes the assumption that <N> refers to the > > > number of sockets, but when no topology description is provided, > > > Linux will use the MPIDR to guess. Neither the MPIDR exposed to > > > the guest when running with KVM nor TCG currently provides socket > > > information, leaving Linux to assume all processing elements are > > > cores in the same socket. For example, before this series '-smp 4' > > > would show up in the guest as > > > > > > CPU(s): 4 > > > On-line CPU(s) list: 0-3 > > > Thread(s) per core: 1 > > > Core(s) per socket: 4 > > > Socket(s): 1 > > > > > > and after it shows up as > > > > > > CPU(s): 4 > > > On-line CPU(s) list: 0-3 > > > Thread(s) per core: 1 > > > Core(s) per socket: 1 > > > Socket(s): 4 > > > > > > It's not expected that this should be a problem, but it's worth > > > considering. The only way to avoid the silent change is for QEMU to > > > provide boards a way to override the default '-smp' parsing function. > > > Otherwise, if a user wants to avoid a guest visible change, but still > > > use a 3.1 or later mach-virt machine type, then they must ensure the > > > command line specifies a single socket, e.g. '-smp sockets=1,cores=4' > > > > > > Thanks, > > > drew > > > > > > > > > Andrew Jones (6): > > > hw/arm/virt: Add virt-3.1 machine type > > > device_tree: add qemu_fdt_add_path > > > hw/arm/virt: DT: add cpu-map > > > hw/arm/virt-acpi-build: distinguish possible and present cpus > > > virt-acpi-build: add PPTT table > > > hw/arm/virt: cpu topology: don't allow threads > > > > > > device_tree.c | 24 +++++++++++++ > > > hw/acpi/aml-build.c | 50 ++++++++++++++++++++++++++ > > > hw/arm/virt-acpi-build.c | 25 ++++++++++--- > > > hw/arm/virt.c | 69 > > > +++++++++++++++++++++++++++++++++--- > > > include/hw/acpi/aml-build.h | 2 ++ > > > include/hw/arm/virt.h | 1 + > > > include/sysemu/device_tree.h | 1 + > > > 7 files changed, 162 insertions(+), 10 deletions(-)
© 2016 - 2024 Red Hat, Inc.