[RFC,0/6] hw/arm/virt: Introduce cpu topology support
mbox series

Message ID 20180704124923.32483-1-drjones@redhat.com
Headers show
Series
  • hw/arm/virt: Introduce cpu topology support
Related show

Message

Andrew Jones July 4, 2018, 12:49 p.m. UTC
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(-)

Comments

Zengtao (B) Dec. 9, 2019, 2:14 a.m. UTC | #1
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).

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(-)
Andrew Jones Dec. 10, 2019, 10:13 a.m. UTC | #2
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(-)
Zengtao (B) Dec. 11, 2019, 11:10 a.m. UTC | #3
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(-)