Hello Jiri, Thanks for the feedback, On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark <jdenemar@redhat.com> wrote:
On Mon, Jun 02, 2025 at 01:19:29 +0200, Hector Cao wrote:
Several Intel CPU models with TSX technology (HLE & RTM features) are affected by the vulnerability TAA[1]. One of the mitigation methods for TAA is to disable TSX support on the host system. For that purpose, in 2021, Intel published a microcode update to disable TSX. Linux kernel also disables TSX globally by default. Even though TSX can be activated via the kernel command line (tsx=on), many Linux distributions stick with this default behavior and have TSX disabled. This makes existing CPU models that have HLE and RTM enabled not correctly detected by libvirt.
Can you describe the issue in more details? Especially where libvirt incorrectly detects CPU models because of this?
On my platform (Granite Rapids CPU) with TSX disabled by default in the kernel The TSX features rtm and hle are missing, per consequence, `virsh capabilities` detects the CPU as Icelake-Server-noTSX model.
This commit adds 2 remaining -noTSX models: - SapphireRapids-noTSX - GraniteRapids-noTSX
QEMU switched away from adding suffixes to CPU models and just adds a new version for a CPU model in case it needs to be updated. There's no point adding these models to libvirt. Any CPU model that would only exist in libvirt would not be directly usable anyway and would have to be translated to another CPU model.
I would be grateful if you can provide me some background on what is the criteria to add a new version to an existing model. For the case of Intel, how do we know that we need to add a new version to the CPU model ? Beyond the naming issue (version vs suffix), I understand that we stopped doing what we did for older CPU models like this commit for Icelake, do I understand it correctly ? i386: Add -noTSX aliases for hle=off, rtm=off CPU models https://github.com/qemu/qemu/commit/02fa60d10137ed2ef17534718d7467e0d2170142 Do you think that adding a new version for Sapphire and Granite Rapids CPU models both in QEMU and libvirt would be something that makes sense to tackle this issue ?
Jirka
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>