On 4/21/25 23:46, Ingo Molnar wrote:
/*
- These CPUs have buggy MWAIT/MONITOR implementations that
- usually manifest as hangs or stalls at boot.
- */
+#define MWAIT_VFM(_vfm) \
- X86_MATCH_VFM_FEATURE(_vfm, X86_FEATURE_MWAIT, 0)
+static const struct x86_cpu_id monitor_bug_list[] = {
- MWAIT_VFM(INTEL_ATOM_GOLDMONT),
- MWAIT_VFM(INTEL_LUNARLAKE_M),
- MWAIT_VFM(INTEL_ICELAKE_X), /* Erratum ICX143 */
- {},
+};
While it's just an internal helper, macro names should still be intuitive:
s/MWAIT_VFM /VFM_MWAIT_BUG
The current convention is to end with the thing that's being matched, like "_FEATURE" or "_VFM" in the X86_MATCH*() macros. That's why I ordered it the way I did.
As for including "BUG", the _macro_ doesn't match CPUs with the bug. It's just matching CPUs with the specified VFM that have MWAIT. It could (theoretically) get used for non-bug things so I don't think it's intuitive to put "BUG" in the name.
But, honestly, we have a tone of these one-off x86_cpu_id macros around. They have lots of pretty silly naming, but they're mostly only used at one isolated site so I don't worry about the naming _too_ much.