vmm: Add core scheduling support for vCPU threads

Add a core_scheduling option to --cpus with three modes of operation.
This feature takes advantage of a kernel feature that restricts
scheduling of processes on the SMT threads on the same core. This is
useful for mitigating certain classes of side-channel attacks and has
better performance that disabling SMT on the CPU.

- vm (default): All vCPU threads share one core scheduling cookie.
  They may be co-scheduled on SMT siblings while host threads are
  excluded - this has minimal performance impact and can even
  potentially improve performance from co-location.
- vcpu: Each vCPU gets a unique cookie preventing any two vCPUs from
  sharing SMT siblings. This has the strongest isolation but at some
  compromise of performance.
- off: No core scheduling applied (old behaviour).

This isolation is done by the kernel maintaining a "cookie" - threads
with the same cookie can share the same core.

In vCPU mode each vCPU thread the cookie is created when the thread
starts and each gets a unique cookie. For VM mode the first vCPU thread
(the leader) will create the cookie. All other vCPU threads started (via
hotplug or during boot) will have that cookie shared to it.

EINVAL/ENODEV from prctl is silently ignored so this works transparently
on kernels older than 5.14 that lack PR_SCHED_CORE or when SMT disabled.

Full details of this kernel feature can be found at:
https://docs.kernel.org/admin-guide/hw-vuln/core-scheduling.html

This implementation was inspired by crosvm's implementation - in
particular the enable_core_scheduling() function.

This is challenging to test via integration testing but the logging of
the received cookie shows it working:

VM case:

cloud-hypervisor:   0.243102s: <vcpu1> INFO:vmm/src/cpu.rs:1247 -- vCPU 1: core scheduling cookie = 0x33e4c167
cloud-hypervisor:   0.243102s: <vcpu0> INFO:vmm/src/cpu.rs:1247 -- vCPU 0: core scheduling cookie = 0x33e4c167

vCPU case:

cloud-hypervisor:   0.089356s: <vcpu0> INFO:vmm/src/cpu.rs:1247 -- vCPU 0: core scheduling cookie = 0x13993ad6
cloud-hypervisor:   0.089380s: <vcpu1> INFO:vmm/src/cpu.rs:1247 -- vCPU 1: core scheduling cookie = 0xd48e86e

Signed-off-by: Rob Bradford <rbradford@meta.com>

docs/cpu.md

@@ -19,11 +19,12 @@ struct CpusConfig {
     affinity: Option<Vec<CpuAffinity>>,
     features: CpuFeatures,
     nested: bool,
+    core_scheduling: CoreScheduling,
 }
 ```
 
 ```
---cpus boot=<boot_vcpus>,max=<max_vcpus>,topology=<threads_per_core>:<cores_per_die>:<dies_per_package>:<packages>,kvm_hyperv=on|off,max_phys_bits=<maximum_number_of_physical_bits>,affinity=<list_of_vcpus_with_their_associated_cpuset>,features=<list_of_features_to_enable>,nested=on|off
+--cpus boot=<boot_vcpus>,max=<max_vcpus>,topology=<threads_per_core>:<cores_per_die>:<dies_per_package>:<packages>,kvm_hyperv=on|off,max_phys_bits=<maximum_number_of_physical_bits>,affinity=<list_of_vcpus_with_their_associated_cpuset>,features=<list_of_features_to_enable>,nested=on|off,core_scheduling=vm|vcpu|off
 ```
 
 ### `boot`
@@ -221,3 +222,34 @@ _Example_
 ```
 --cpus nested=on
 ```
+
+### `core_scheduling`
+
+Core scheduling mode for vCPU threads.
+
+This option controls Linux core scheduling (`PR_SCHED_CORE`) for vCPU threads,
+which prevents untrusted tasks from sharing SMT siblings. This mitigates
+side-channel attacks (e.g. MDS, L1TF) between vCPU threads.
+
+Three modes are available:
+
+- `vm` (default): All vCPU threads share a single core scheduling cookie.
+  vCPUs may be co-scheduled on SMT siblings of the same core, providing
+  better performance while still isolating VM threads from host tasks.
+- `vcpu`: Each vCPU thread gets its own unique cookie. No two vCPUs can
+  share SMT siblings, providing the strongest isolation between vCPUs at
+  the cost of performance.
+- `off`: No core scheduling is applied.
+
+On kernels older than 5.14 (which lack `PR_SCHED_CORE` support), the
+option silently has no effect.
+
+_Example_
+
+```
+--cpus boot=2,core_scheduling=vm
+```
+
+In this example, both vCPUs will share the same core scheduling cookie,
+allowing them to be co-scheduled on SMT siblings while preventing host
+threads from sharing those siblings.