linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
	tony.luck@intel.com, x86@kernel.org,
	Smita.KoralahalliChannabasappa@amd.com
Subject: Re: [PATCH 00/25] AMD MCA Address Translation Updates
Date: Tue, 18 May 2021 23:52:07 -0400	[thread overview]
Message-ID: <20210519035207.GA8913@aus-x-yghannam.amd.com> (raw)
In-Reply-To: <YKJoICQzD/o7ZPBp@zn.tnic>

On Mon, May 17, 2021 at 02:57:04PM +0200, Borislav Petkov wrote:
> On Fri, May 07, 2021 at 03:01:15PM -0400, Yazen Ghannam wrote:
> > Patches 1-24 do the refactor without adding new system support. The goal
> > is to break down the translation algorithm into smaller chunks. There
> > are some simple wrapper functions defined. These will be filled in when
> > supporting newer systems. The intention is that new system support can
> > be added without any major refactor. I tried to make a patch for each
> > logical change. There's a bit of churn so as to not break the build with
> > each change. I think many of these patches can be squashed together, if
> > desired. The top level function was split first, then the next level of
> > functions, etc. in a somewhat breadth-first approach.
> 
> No, that's great what you did and keeping each logical change in a
> single patch is a lot easier on everybody involved.
> 
> Now, looking at this - and I know we've talked about this before - but:
> 
> umc_normaddr_to_sysaddr() is used only in amd64_edac.c.
> amd_df_indirect_read() is used only by this function, so how about
> moving both to amd64_edac, where they're needed and then doing the
> refactoring ontop?
> 
> You can simply reuse your current patches - just change the file they
> patch from
> 
> arch/x86/kernel/cpu/mce/amd.c
> 
> to
> 
> drivers/edac/amd64_edac.c
> 
> I went through te umc_... function and AFAICT, it doesn't need any core
> MCE facilities so it should be just fine in EDAC land.
> 
> Or?
>

I think this is a good idea. The only hang up is that we should be using
the output of this function, i.e. the systeme physical address, when
handling memory errors in the MCE notifier blocks. But I have an idea
where we can handle this. I can send that as a follow up series, if
that's okay.

One other issue is what if a user doesn't want to use amd64_edac_mod?
This is more of a user preference and/or configuration issue. Maybe the
module loads, but an uninterested user can tell EDAC to not log errors,
etc.? Or should the translation code live in its own module?

So for version 2, I have 1) Add a glossary of terms, and 2) Move
everything to EDAC. Any other comments?

Thanks,
Yazen

  reply	other threads:[~2021-05-19  3:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07 19:01 [PATCH 00/25] AMD MCA Address Translation Updates Yazen Ghannam
2021-05-07 19:01 ` [PATCH 01/25] x86/MCE/AMD: Don't use naked values for DF registers Yazen Ghannam
2021-05-07 19:01 ` [PATCH 02/25] x86/MCE/AMD: Add context struct Yazen Ghannam
2021-05-07 19:01 ` [PATCH 03/25] x86/MCE/AMD: Define functions for DramOffset Yazen Ghannam
2021-05-07 19:01 ` [PATCH 04/25] x86/MCE/AMD: Define function to read DRAM address map registers Yazen Ghannam
2021-05-07 19:01 ` [PATCH 05/25] x86/MCE/AMD: Define function to find interleaving mode Yazen Ghannam
2021-05-07 19:01 ` [PATCH 06/25] x86/MCE/AMD: Define function to denormalize address Yazen Ghannam
2021-05-07 19:01 ` [PATCH 07/25] x86/MCE/AMD: Define function to add DRAM base and hole Yazen Ghannam
2021-05-07 19:01 ` [PATCH 08/25] x86/MCE/AMD: Define function to dehash address Yazen Ghannam
2021-05-07 19:01 ` [PATCH 09/25] x86/MCE/AMD: Define function to check DRAM limit address Yazen Ghannam
2021-05-07 19:01 ` [PATCH 10/25] x86/MCE/AMD: Remove goto statements Yazen Ghannam
2021-05-07 19:01 ` [PATCH 11/25] x86/MCE/AMD: Simplify function parameters Yazen Ghannam
2021-05-07 19:01 ` [PATCH 12/25] x86/MCE/AMD: Define function to get Interleave Address Bit Yazen Ghannam
2021-05-07 19:01 ` [PATCH 13/25] x86/MCE/AMD: Skip denormalization if no interleaving Yazen Ghannam
2021-05-07 19:01 ` [PATCH 14/25] x86/MCE/AMD: Define function to get number of interleaved channels Yazen Ghannam
2021-05-07 19:01 ` [PATCH 15/25] x86/MCE/AMD: Define function to get number of interleaved dies Yazen Ghannam
2021-05-07 19:01 ` [PATCH 16/25] x86/MCE/AMD: Define function to get number of interleaved sockets Yazen Ghannam
2021-05-07 19:01 ` [PATCH 17/25] x86/MCE/AMD: Remove unnecessary assert Yazen Ghannam
2021-05-07 19:01 ` [PATCH 18/25] x86/MCE/AMD: Define function to make space for CS ID Yazen Ghannam
2021-05-07 19:01 ` [PATCH 19/25] x86/MCE/AMD: Define function to calculate " Yazen Ghannam
2021-05-07 19:01 ` [PATCH 20/25] x86/MCE/AMD: Define function to insert CS ID into address Yazen Ghannam
2021-05-07 19:01 ` [PATCH 21/25] x86/MCE/AMD: Define function to get CS Fabric ID Yazen Ghannam
2021-05-07 19:01 ` [PATCH 22/25] x86/MCE/AMD: Define function to find shift and mask values Yazen Ghannam
2021-05-07 19:01 ` [PATCH 23/25] x86/MCE/AMD: Update CS ID calculation to match reference code Yazen Ghannam
2021-05-07 19:01 ` [PATCH 24/25] x86/MCE/AMD: Match hash function to " Yazen Ghannam
2021-05-07 19:01 ` [PATCH 25/25] x86/MCE/AMD: Add support for address translation on DF3 systems Yazen Ghannam
2021-05-07 20:32 ` [PATCH 00/25] AMD MCA Address Translation Updates Randy Dunlap
2021-05-11 15:42   ` Yazen Ghannam
2021-05-11 16:13     ` Randy Dunlap
2021-05-11 16:28       ` Borislav Petkov
2021-05-17 12:57 ` Borislav Petkov
2021-05-19  3:52   ` Yazen Ghannam [this message]
2021-05-19 14:32     ` 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=20210519035207.GA8913@aus-x-yghannam.amd.com \
    --to=yazen.ghannam@amd.com \
    --cc=Smita.KoralahalliChannabasappa@amd.com \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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).