Emerald Rapids cannot be used as Sapphire Rapids on Ubuntu due to TSX features

Hey hector, I subscribed you as this is all related to the topic you already work on.

The reason virsh detects Broadwell-noTSX-IBRS model in Jammy instead of SapphireRapids-noTSX is due to the fact that libvirt cannot detect taa-no feature because the msr kernel module is not loaded and as a consequence the files /dev/cpu/*/msr are not populated.

taa-no feature is specified as the 8th bit of the 0x10A MSR register
and libvirt needs the msr kernel module to detect the feature.

Reproduce instructions:
---

$ Boot the machine (make sure to not have tsx=on in the kernel commandline, by default tsx will be disabled)
$ virsh capabilities
  --> Detected model : Broadwell-noTSX-IBRS
$ sudo modprobe msr
$ sudo systemctl restart libvirtd
$ virsh capabilities
  --> Detected model : SapphireRapids-noTSX

This is a great analysis and insight,
which in turn means we probably should configure the system to load it.

As you work on a whole set of fixes around the same topic this probably needs to go together with the right types added and so on - you know it better already :-)

But for the module we might want to use:
- https://www.freedesktop.org/software/systemd/man/latest/modules-load.d.html
- only on the two x86 arches as that is where msr applies
- something like https://sources.debian.org/src/cups-filters/1.28.17-6/debian/rules/?hl=64#L64
- but today better into the non-user dir of /usr/lib/modules-load.d/
- and for the before-boot maybe add a modprobe to postinst

This should affect Debian as well (can't check their kernel config atm if it is a module) and fixing it with them has the benefit of not conflicting and making the merge more complex later, so a PR should probably best land in https://salsa.debian.org/libvirt-team/libvirt first, which would be picked up by questing and then SRUed once the other "detect my type" cases are ready as well.

Until then anyone affected has a workaround with the above already.

In Debian Sid:

debian@localhost:~$ uname -r
6.12.29-amd64

debian@localhost:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.0
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

The module MSR is not built-in:

CONFIG_X86_MSR=m

Status changed to 'Confirmed' because the bug affects multiple users.

@Christian : all the MPs are updated to enable the MSR module load, please take a look.

A bit of context for others : most of the time, libvirt cannot output the right host CPU model name, this is due to various reasons. One of them is some features are disabled by the kernel for security reasons, the other reason is libvirt being unable to detect some features via MSRs registers.

This fix only attempts to fix the second part (MSR read).

Oracular will be EOL before this can land, for the rest this LGTM
I've updated SRU template to be more acceptable, hope it is good now.
In -devel I'd like to have the Debian submission done and referenced, then we can go on.