Re: [PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
On Mon, Jun 16, 2025 at 02:14:15 +0200, Hector Cao wrote:
On Mon, Jun 2, 2025 at 3:23 PM Jiří Denemark
<jdenemar(a)redhat.com> wrote:
> So except for not having the right CPU model in the capabilities XML
> (which is not a bug, but rather a known limitation), is there any other
> issue? I believe the host CPU would be correctly reported as
> SapphireRapids/GraniteRapids with both hle and rtm disabled in domain
> capabilities XML.
>
>
Yes, you are right, if rtm and hle features are available, Granite Rapids
will be correctly reported by virsh capabilities
if the MSR bug is fixed (please take a look at :
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XN...
)
You are also right that this is not a bug but rather a known limitation.
However, we are getting regular bug reports from users who are not aware of
this known limitation and
are confused. I would think if we can offer a better experience and save
time for everyone, It might be worth the
effort, especially GraniteRapids would be the last CPU model affected by
this issue.
A better experience that would actually work would be allowing CPU
features to be shown as disabled in host capabilities. But unfortunately
we can't do that for compatibility reasons. The CPU description in host
capabilities does not include the "policy" attribute and adding it could
result in apps thinking disabled features are actually enabled (because
they don't know they should read an extra attribute).
If you still believe that this little effort is not useful, I would
think
I do. It would only fix a few specific cases, but the same issue could
happen with other (even existing) CPU models and different features too.
It just depends on the exact host CPU and even BIOS settings.
that we can tackle this issue by offering better documentation about
this known limitation. What do you think ? We are thinking about
documenting it on Ubuntu but do you think that we can do something
more upstream ?
Yes, this should be fixed by a documentation. It should definitely go
upstream (and any relevant downstream documentation as well) unless it's
already there or in case it's clear enough or not in the right place.
Jirka