On Tue, Jun 15, 2021 at 11:16:49AM +0200, Borislav Petkov wrote:

On Mon, Jun 14, 2021 at 10:25:36PM +0000, Luck, Tony wrote:

quoted

I expect all the Intel EDAC drivers that load based on CPU model have similar
issues. Maybe they aren't whining as loudly about not being able to find the
memory controller devices?

Right.

quoted

Though perhaps this is an issue outside of EDAC and x86_match_cpu()
could do the HYPERVISOR check and return no match. The few callers
who want to believe the fictional CPU model number passed in by the
VMM would need to use some new variant of the call?

Yeah, we could do

X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_NOT_FEATURE

notice the "NOT" and have a x86_cpu_id.not_feature which to match
X86_FEATURE_HYPERVISOR. I'm not sure it is worth it, though, for a
handful of drivers.

The whole thing is a meh, why bother, but I got tired of this particular
intent of people wanting to shut this error message up just because they
should not load that driver in a VM in the first place.

But what happens is they boot a guest with -cpu host and in that case
that's a new CPU - family 0x19 - so it doesn't have a case 0x19 for the
pr_warn_once() there.

And instead of keep adding adding families there, I'd simply check
X86_FEATURE_HYPERVISOR.

Oh and that thing - mce_amd.c - doesn't use x86_match_cpu() so it has to
be an explicit check on function entry.

How about adding the the SMCA feature to the amd64_cpuids[] table in
amd64_edac.c?

We can use X86_MATCH_VENDOR_FEATURE to match on AMD (and Hygon) systems
with SMCA. And we can remove the X86_MATCH_VENDOR_FAM entries for
families 17h-19h.

I'm assuming the issue is that amd64_edac_mod is autoloading due to the
family-based device table, and this will load edac_mce_amd as a
dependency.

Thanks,
Yazen