Connect nosmt/smt=? kernel arguments (used on x86, s390) to our smt-enabled logic

[mpe]

We've had smt-enabled since 2004 :smile_cat:

https://github.com/mpe/linux-fullhistory/commit/157e7a9617c8d3baa45eda4ff3071c2d0b4ccf9d

Wiring it up to the new parameter names would be good I guess.

[grooverdan]

• add docs :astonished: for ^ into Documentation/admin-guide/kernel-parameters.txt

[ghost]

Daniel Black notifications@github.com writes:

• add docs :astonished: for ^ into Documentation/admin-guide/kernel-parameters.txt

We should probably also fix the inevitable bugs of using it under OPAL.

-- Stewart Smith OPAL Architect, IBM.

[mpe]

Yeah the reason it's undocumented is we don't want to support it, because it is very good at causing bugs.

[mpe]

There's also sysfs knobs: see torvalds/linux@05736e4ac13c08a4a9b1ef2de26dd31a32cbee57

[mpe]

@shenki had a stab at this, it somewhat works, but needs a few issues ironed out before it will be mergeable.

http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20220217070419.351683-1-joel@jms.id.au/

[mpe]

In addition to the issues mentioned in the patch, there are some build errors on ppc64e:

/linux/kernel/cpu.c:2220:9: error: implicit declaration of function 'cpu_down_maps_locked' [-Werror,-Wimplicit-function-declaration] ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);

[shenki]

To test, here's a buildroot defconfig that contains ppc64_cpu:

BR2_powerpc64le=y
BR2_powerpc_power8=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TARGET_GENERIC_GETTY_PORT="hvc0"
BR2_SYSTEM_DHCP="eth0"
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_POWERPC_UTILS=y
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_ROOTFS_CPIO_GZIP=y
# BR2_TARGET_ROOTFS_TAR is not set

It uses the prebuilt toolchain which makes it quite quick to build, but relies on an x86 host. The image I was using has been uploaded here: https://ozlabs.org/~joel/rootfs-ppc64_cpu.cpio.gz

We can use ppc64le_guest_defconfig to get a working configuration (ppc64le_defconfig is ok too, but won't have working networking without changing CONFIG_IBMVETH from =m to =y. The upside is it's the default nic device in the pseries machine, so the qemu command line is shorter).

To test I was building my own qemu (7.0-ish) so we can use the super speedy x-vof. Remove -enable-kvm if you're not on a ppc host:

~/qemu/build/qemu-system-ppc64 -enable-kvm -smp 8,threads=4 \
 -M pseries,cap-ccf-assist=off,x-vof=on -nographic -nodefaults \
 -kernel /dev/shm/obj/vmlinux -initrd rootfs-ppc64_cpu.cpio.gz \
 -net nic,model=virtio-net-pci -net user -serial mon:stdio

The patch has some commands for testing:

For displaying the current state:

ppc64_cpu --info
grep . /sys/devices/system/cpu/smt/*

Turning off SMT

echo off > /sys/devices/system/cpu/smt/control

ppc64_cpu --smt=off

And adding -append nosmt to qemu.

Turning on SMT

echo on > /sys/devices/system/cpu/smt/control

ppc64_cpu --smt=on

A compromise in getting this working could be to change the core code to not support nosmt on the command line, to avoid the bugs that mpe mentions often come up with the boot time option.

[nathanlynch]

If we do this for powerpc, the pseries cpu DLPAR code will need to be made aware so it can apply the policy to newly-added processors.

[mpe]

This is mostly done as of torvalds/linux@d1099e2276df.

What's missing is that the smt-enabled command line option is still handled separately from the generic SMT logic. And also there is no smt=x commandline option.