From: Borislav Petkov <bp@alien8.de>
To: Yazen Ghannam <yazen.ghannam@amd.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
James Morse <james.morse@arm.com>,
Robert Richter <rric@kernel.org>
Subject: Re: [PATCH] EDAC/mce_amd: Reduce unnecessary spew in dmesg if SMCA feature bit is not exposed
Date: Tue, 15 Jun 2021 18:11:04 +0200 [thread overview]
Message-ID: <YMjRGFiqp2HNWUrZ@zn.tnic> (raw)
In-Reply-To: <20210615160009.GA29258@aus-x-yghannam.amd.com>
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
next prev parent reply other threads:[~2021-06-15 16:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 21:21 [PATCH] EDAC/mce_amd: Reduce unnecessary spew in dmesg if SMCA feature bit is not exposed Smita Koralahalli
2021-06-14 22:01 ` Borislav Petkov
2021-06-14 22:25 ` Luck, Tony
2021-06-15 9:16 ` Borislav Petkov
2021-06-15 15:08 ` Yazen Ghannam
2021-06-15 15:18 ` Borislav Petkov
2021-06-15 16:00 ` Yazen Ghannam
2021-06-15 16:11 ` Borislav Petkov [this message]
2021-06-15 16:32 ` Yazen Ghannam
2021-06-15 16:45 ` [PATCH] EDAC/Intel: Do not load EDAC driver when running as a guest Luck, Tony
2021-06-15 17:00 ` Borislav Petkov
2021-06-15 17:44 ` [PATCH v2] " Luck, Tony
2021-06-15 17:25 ` [PATCH] EDAC/mce_amd: Reduce unnecessary spew in dmesg if SMCA feature bit is not exposed Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMjRGFiqp2HNWUrZ@zn.tnic \
--to=bp@alien8.de \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=james.morse@arm.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rric@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yazen.ghannam@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).