[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YMjRGFiqp2HNWUrZ@zn.tnic>
Date: Tue, 15 Jun 2021 18:11:04 +0200
From: Borislav Petkov <bp@...en8.de>
To: Yazen Ghannam <yazen.ghannam@....com>
Cc: "Luck, Tony" <tony.luck@...el.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
James Morse <james.morse@....com>,
Robert Richter <rric@...nel.org>
Subject: Re: [PATCH] EDAC/mce_amd: Reduce unnecessary spew in dmesg if SMCA
feature bit is not exposed
On Tue, Jun 15, 2021 at 12:00:09PM -0400, Yazen Ghannam wrote:
> So I think we can downgrade this warning to a debug message, if the
> module stays builtin. And/or we change the default config option to
> module, and we make sure the module only autoloads in the proper cases.
>
> What do you think?
I think, as I said before, that we should simply not load this in
guests. Then this will be taken care of once and for all and we can do
whatever we want on baremetal, as to what error message to issue and how
many times to issue it, whether the decoder is builtin or default y or
yadda yadda.
Because even if you say in a guest:
pr_warn_once("Decoding supported only on Scalable MCA processors.\n");
you're kinda misleading because the guest might be an SMCA processor but
not all features are emulated, including SMCA. So it is not really an
SMCA processor but some not really existant hybrid or so.
So since this whole SMCA thing does not apply to virtualization, we
should simply not load on virt and be done with it.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists