From: Yazen Ghannam <yazen.ghannam@amd.com>
To: bp@alien8.de, linux-edac@vger.kernel.org, hdegoede@redhat.com,
markgross@kernel.org, platform-driver-x86@vger.kernel.org, "Luck,
Tony" <tony.luck@intel.com>
Cc: yazen.ghannam@amd.com, linux-kernel@vger.kernel.org,
avadhut.naik@amd.com, mario.limonciello@amd.com
Subject: Re: [PATCH 1/2] platform/x86/amd: Introduce AMD Address Translation Library
Date: Mon, 7 Aug 2023 16:44:08 -0400 [thread overview]
Message-ID: <58934edf-4fad-48e0-bc5d-62712b11e607@amd.com> (raw)
In-Reply-To: <20230802185504.606855-2-yazen.ghannam@amd.com>
On 8/2/2023 2:55 PM, Yazen Ghannam wrote:
> AMD Zen-based systems report memory errors through Machine Check banks
> representing Unified Memory Controllers (UMCs). The address value
> reported for DRAM ECC errors is a "normalized address" that is relative
> to the UMC. This normalized address must be converted to a system
> physical address to be usable by the OS.
>
> Support for this address translation was introduced to the MCA subsystem
> with Zen1 systems. The code was later moved to the AMD64 EDAC module,
> since this was the only user of the code at the time.
>
> However, there are uses for this translation outside of EDAC. The system
> physical address can be used in MCA for preemptive page offlining as done
> in some MCA notifier functions. Also, this translation is needed as the
> basis of similar functionality needed for some CXL configurations on AMD
> systems.
>
> Introduce a common address translation library that can be used for
> multiple subsystems including MCA, EDAC, and CXL.
>
> Include support for UMC normalized to system physical address
> translation for current CPU systems.
>
> Future development to include:
> - DF4.5 Non-power-of-2 interleaving modes.
> - Heterogeneous CPU+GPU system support.
> - CXL translation support.
> - Caching of common intermediate values and results.
> - Leverage UEFI PRM methods as alternate backends to existing native
> code.
>
> Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
> ---
> MAINTAINERS | 7 +
> drivers/platform/x86/amd/Kconfig | 1 +
> drivers/platform/x86/amd/Makefile | 1 +
> drivers/platform/x86/amd/atl/Kconfig | 20 +
> drivers/platform/x86/amd/atl/Makefile | 18 +
> drivers/platform/x86/amd/atl/access.c | 107 ++++
> drivers/platform/x86/amd/atl/core.c | 212 +++++++
> drivers/platform/x86/amd/atl/dehash.c | 459 ++++++++++++++
> drivers/platform/x86/amd/atl/denormalize.c | 644 ++++++++++++++++++++
> drivers/platform/x86/amd/atl/internal.h | 307 ++++++++++
> drivers/platform/x86/amd/atl/map.c | 659 +++++++++++++++++++++
> drivers/platform/x86/amd/atl/reg_fields.h | 603 +++++++++++++++++++
> drivers/platform/x86/amd/atl/system.c | 282 +++++++++
> drivers/platform/x86/amd/atl/umc.c | 53 ++
> include/linux/amd-atl.h | 18 +
>
Hi all,
I'd like to get feedback on the most appropriate place for this code.
I want to move this out of EDAC, since it's not really an EDAC feature.
And it needs to be used by subsystems other than EDAC.
I thought x86 Platform Drivers, because the code is very
platform-specific. And there are already some AMD platform drivers. But
there isn't any platform control or management for this translation.
It's just reading registers and calculating values. So it's not really a
"platform driver" in the sense that it manages platform-specific behavior.
Another option is for this code to be in arch/x86/ras/. But I would like
the option for this code to be built as a module, at least for debug and
development. And I don't know that modules, nor platform-specific code,
should be in arch/.
Currently, I think this could go in drivers/ras/. This address
translation is needed for RAS use cases, so making it a part of "RAS
Infrastructure" may make the most sense.
Boris, Tony, (and others) what do you think?
Thanks,
Yazen
next prev parent reply other threads:[~2023-08-07 20:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 18:55 [PATCH 0/2] " Yazen Ghannam
2023-08-02 18:55 ` [PATCH 1/2] platform/x86/amd: Introduce " Yazen Ghannam
2023-08-07 20:44 ` Yazen Ghannam [this message]
2023-08-08 3:17 ` Limonciello, Mario
2023-08-08 12:10 ` Borislav Petkov
2023-08-08 14:07 ` Yazen Ghannam
2023-08-08 14:20 ` Borislav Petkov
2023-08-08 14:28 ` Yazen Ghannam
2023-08-08 14:37 ` Borislav Petkov
2023-08-08 15:18 ` Yazen Ghannam
2023-08-08 15:58 ` Borislav Petkov
2023-08-08 16:24 ` Yazen Ghannam
2023-08-09 14:38 ` Hans de Goede
2023-08-09 15:05 ` Yazen Ghannam
2023-08-02 18:55 ` [PATCH 2/2] EDAC/amd64: Use new " Yazen Ghannam
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=58934edf-4fad-48e0-bc5d-62712b11e607@amd.com \
--to=yazen.ghannam@amd.com \
--cc=avadhut.naik@amd.com \
--cc=bp@alien8.de \
--cc=hdegoede@redhat.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=markgross@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tony.luck@intel.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
all inboxes | Powered by JetHome®