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....@nongnu.or > > g] On Behalf Of Andrew Jones > > Sent: Thursday, July 05, 2018 4:49 AM > > To: qemu-devel@nongnu.org; qemu-...@nongnu.org > > Cc: w...@redhat.com; peter.mayd...@linaro.org; eric.au...@redhat.com; > > imamm...@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(-)
