Re: [Qemu-devel] [RFC PATCH 0/6] hw/arm/virt: Introduce cpu topology support

[Andrew Jones]

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=address@hidden
> > g] On Behalf Of Andrew Jones
> > Sent: Thursday, July 05, 2018 4:49 AM
> > To: address@hidden; address@hidden
> > Cc: address@hidden; address@hidden; address@hidden;
> > address@hidden
> > 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(-)