Received-SPF: pass (google.com: domain of linux-kernel+bounces-159393-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
From: Ashish Kalra <Ashish.Kalra@amd.com>
To: <tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
	<jbohac@suse.cz>, <dyoung@redhat.com>, <luto@kernel.org>
CC: <rafael@kernel.org>, <peterz@infradead.org>, <adrian.hunter@intel.com>,
	<sathyanarayanan.kuppuswamy@linux.intel.com>, <jun.nakajima@intel.com>,
	<rick.p.edgecombe@intel.com>, <thomas.lendacky@amd.com>,
	<michael.roth@amd.com>, <seanjc@google.com>, <kai.huang@intel.com>,
	<bhe@redhat.com>, <kirill.shutemov@linux.intel.com>, <jroedel@suse.de>,
	<ardb@kernel.org>, <kevinloughlin@google.com>, <kexec@lists.infradead.org>,
	<linux-coco@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Subject: [PATCH v3 0/2] Apply RMP table fixups for kexec.
Date: Fri, 26 Apr 2024 00:41:38 +0000
Message-ID: <cover.1714090302.git.ashish.kalra@amd.com>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2024 00:41:49.1282
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: de07bcb7-156b-47e5-4342-08dc6589a886
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN3PEPF0000B06A.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB6922

From: Ashish Kalra <ashish.kalra@amd.com>

Handle cases where the RMP table placement in the BIOS is
not 2M aligned and then the kexec kernel could try to allocate
from within that chunk and that causes a fatal RMP fault.

Check if RMP table start & end physical range in e820 tables
are not aligned to 2MB and in that case map this range to reserved
in all the three e820 tables.

The callback to apply these RMP table fixups needs to be called
after the e820 tables are setup/populated and before the e820 map
has been converted to the standard Linux memory resources and e820 map
is no longer used and modifying it has no effect.

v3:
- Added new e820__range_update_table() helper and updated all
  internal and external modifiers of e820_table_kexec and 
  e820_table_firmware to call this new helper function.
- Updated and restructured the commit message for patch 2/2 to
  explain the issue in detail.
- Added, merged and cleaned up inline comments in patch 2/2.
- Added new __snp_e820_tables_fixup() function to be avoid
  duplication of code for fixing both RMP table start and end
  physical ranges.

v2:
- Remove overriding e820__memory_setup_default() to invoke
  snp_rmptable_e820_fixup() to apply the RMP table fixups.
- This callback snp_rmptable_e820_fixup() is now invoked
  after e820__memory_setup() and before e820__reserve_resources().
- Expose e820 API interfaces to update e820_table_kexec and
  e820_table_firmware externally.
- snp_rmptable_e820_fixup() now calls these new external API
  interfaces to update e820_table_kexec and e820_table_firmware.

Ashish Kalra (2):
  x86/e820: Expose API to update e820 kexec and firmware tables
    externally.
  x86/sev: Add callback to apply RMP table fixups for kexec

 arch/x86/include/asm/e820/api.h |  2 ++
 arch/x86/include/asm/sev.h      |  2 ++
 arch/x86/kernel/e820.c          |  6 ++---
 arch/x86/mm/mem_encrypt.c       | 13 ++++++++++
 arch/x86/virt/svm/sev.c         | 42 +++++++++++++++++++++++++++++++++
 5 files changed, 62 insertions(+), 3 deletions(-)

-- 
2.34.1