This is kind of the reverse/dual of bug #324882 (CPUID should depend on VEX capabilities, not on underlying CPU) and bug #211499 (Option to return values from processor's native cpuid instruction). The meta request would be to make cpuid selection/emulation more flexible.

Currently if we select the amd64g_dirtyhelper_CPUID_avx_and_cx16 (but not for amd64g_dirtyhelper_CPUID_avx2?) we claim to support RTM (restructed transactual memory) by setting bit 11 for AEX=7 (extended feature flags).

So it might happen that we say we support HTM even if the underlying processor doesn't.

This is technically correct since VEX does always support xtest/xbegin/xend. But the implementation is kind of bogus. It always immediately aborts the transaction. So while it is good for testing your code works fine under that condition it isn't super useful otherwise. And it might confuse people who don't expect the transactional instructions to be used at all because their cpu doesn't natively support them.

As long as we don't have a more flexible mechanism for selecting the cpuid bits to support maybe this one should default to off in all cases?