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://launchpad.net/~hectorcao