I'm not sure how to work around this cleanly when deploying a KVM pod.
We can add an /etc/rc.local similar to the following:
#!/bin/sh
ppc64_cpu --smt=off
exit 0
... which I prototyped, but I'm not sure about. It really seems like a hack. For example, is there a chance that libvirtd could start up before this gets executed? If so, what would be the effects of that race condition? (Is there another solution, such as a kernel parameter or sysctl, that would be better?)
Given that SMT refers to multithreaded CPU cores, would passing `smt=1` as a kernel parameter be more efficient at accomplishing this? (According to what I found in kernel-parameters.txt in the Linux documentation, smt=1 and nosmt are equivalent, but nosmt=force might be even safer.)
We should test this on actual hardware to confirm any proposed solution before moving forward with this.
I'm not sure how to work around this cleanly when deploying a KVM pod.
We can add an /etc/rc.local similar to the following:
#!/bin/sh
ppc64_cpu --smt=off
exit 0
... which I prototyped, but I'm not sure about. It really seems like a hack. For example, is there a chance that libvirtd could start up before this gets executed? If so, what would be the effects of that race condition? (Is there another solution, such as a kernel parameter or sysctl, that would be better?)
Given that SMT refers to multithreaded CPU cores, would passing `smt=1` as a kernel parameter be more efficient at accomplishing this? (According to what I found in kernel- parameters. txt in the Linux documentation, smt=1 and nosmt are equivalent, but nosmt=force might be even safer.)
We should test this on actual hardware to confirm any proposed solution before moving forward with this.