Hello Jiri, Thanks for the feedback,
On Mon, Jun 2, 2025 at 9:30 AM Jiri Denemark <jdene...@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....@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
