[Feature request] Add support to lxc.sched.core into container configuration.

[yurip]

I was recently making security adjustments to a server with an older processor that is "SMT vulnerable." I discovered that LXC includes a configuration option—lxc.sched.core = 1—that can mitigate this type of vulnerability without requiring me to completely disable hyperthreading. According to the documentation, this setting prevents different containers from sharing the same physical CPU core at the exact same time.

While this protection does incur some CPU overhead, it is significantly less costly than simply discarding logical threads entirely. However, when I added the line lxc.sched.core: 1 to the container configuration, I encountered a parse error: "unable to parse config: lxc.sched.core: 1".

I can bypass this error by adding lxc.sched.core to the list of valid keys in /usr/share/perl5/PVE/LXC/Config.pm. The obvious drawback, however, is that this change will be lost the next time the file is overwritten during an update.

My request is for this option to be officially added to the configuration file so that it can be used reliably. Alternatively, a more sophisticated—and more automated and secure—approach would be to enable lxc.sched.core by default for containers running on nodes identified as "SMT vulnerable" (based on the vulnerability status reported in /sys/devices/system/cpu/vulnerabilities/*).

Below are further details regarding this option, as described in the `lxc.container.conf` manual page:

CORE SCHEDULING
Core scheduling defines if the container payload is marked as being schedulable on the same core. Doing so will cause the kernel scheduler to ensure that tasks that are not in the same group never run simultaneously on a core.
This can serve as an extra security measure to prevent the container payload from using cross hyper thread attacks.

lxc.sched.core
The only allowed values are 0 and 1. Set this to 1 to create a core scheduling domain for the container or 0 to not create one. If not set explicitly no core scheduling domain will be created for the container.