Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Eric DeVolder <eric.devolder@oracle.com>
To:     linux-kernel@vger.kernel.org, x86@kernel.org,
        kexec@lists.infradead.org, ebiederm@xmission.com,
        dyoung@redhat.com, bhe@redhat.com, vgoyal@redhat.com
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, hpa@zytor.com,
        nramas@linux.microsoft.com, thomas.lendacky@amd.com,
        robh@kernel.org, efault@gmx.de, rppt@kernel.org,
        konrad.wilk@oracle.com, boris.ostrovsky@oracle.com,
        eric.devolder@oracle.com
Subject: [PATCH v4 00/10] crash: Kernel handling of CPU and memory hot un/plug
Date:   Wed,  9 Feb 2022 14:56:56 -0500
Message-Id: <20220209195706.51522-1-eric.devolder@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?vWoz2T7Dd2DTDEexd1ZVvfbLviSdX/1iEw09pOIboD5qOpwEJwE6V+21t0TA?=
 =?us-ascii?Q?qT9i39GfwdBfQe1rhBajez8hM7J/7cG7TsQU+zXhia99NTrAdjW0eN2K0I6T?=
 =?us-ascii?Q?NiW5WXzWlgeHzIPPK1SU5KzcJe/WO1DlYcYT/APSgeWyWf3xvP5MwxZ8GBKs?=
 =?us-ascii?Q?48g8rMBlcA1CTkhz0nOXAZ4pa/dztHhzQSK2XBWboleNth9BTkWcyLXOXDU1?=
 =?us-ascii?Q?FqFd38CB+K0SOz+YlMGi0C+xIWuQjZv0VdT8/O5UtixOm8rQCf634HemBRIu?=
 =?us-ascii?Q?qp8Q0B0K29LMGB3UWhB1wzDINgt/irxNDhGANceZX0ry4lCs+QxK1mm+dw3H?=
 =?us-ascii?Q?fzC9qI0VwpcpcynfN5IU5mYCDVCsrAc0Kht5wUCWcdnsUmkFWdUF7/Ivx4Wi?=
 =?us-ascii?Q?lxjT9mswnmI9c5EXXWkR4ae8XJDxAsa/LERMpmWC6oFZmlYymtkWwEuElT7T?=
 =?us-ascii?Q?Q5vIj27yxEu7r0o++5jKiupDXxl6aPM2gB5XU+nDPyxmjA4HJg7Ykn7rFsji?=
 =?us-ascii?Q?NrfderMlB+JvHvhKsPlcUIi903eMUaknD5UbWyd3/n9NlRIboTtQd4k0C12q?=
 =?us-ascii?Q?DvDQmTFgKqYkES+Bjr/Y73FqY+3YFnaQGyvGPfhgLLyai74AN6qJWgwYRx05?=
 =?us-ascii?Q?gFQvopFmk6/6Aig6X8YOxJh2JrQOAW9szQT/ayg9WG9gcE3aS0Ka3uV/LA8r?=
 =?us-ascii?Q?sBi01CV0El5I5LflzUWtUHaNmpdwEiXE2KhULweveZyPqkj6VX04uUl1e3OT?=
 =?us-ascii?Q?GfKYD4LACxcZtZicZNuXMAw3r3GV8QtuYaQy+2RPoh/+lBXQwDFQxcoQoD0v?=
 =?us-ascii?Q?3NSGSacN08ID3ldc62iZZ+KTt9t7FMRRpYByx9R09jM9faosBSal8+ymv7SQ?=
 =?us-ascii?Q?o7Z+1j+adLSmFn01dKCC6LulEiDX1gXNhcPg5UCR8CCDtRz946L3m+Wa0i19?=
 =?us-ascii?Q?7bDepSSXRFkR82XD7mfYXuCz29OiCtvm76+5mVitmBQ0yc7Ktd8Rwa09Ovsa?=
 =?us-ascii?Q?bwlFJ2dtSX6GJ7Qz7VIg9o7ZIfkkNlfOeur/FP93Z0ODkT9PmRbx6llxftLN?=
 =?us-ascii?Q?b0V5T2YW5OkG1rX/uCxlYAJ4oBwFa2BnxRqFEk8HhHtyw5I/yVvvKV7pdB3E?=
 =?us-ascii?Q?BrQwQj4hiBrWyMXFFnjK9un2d72CZD3h5Lll244b18w2PO05OvSg1NfnUXtT?=
 =?us-ascii?Q?iajIu7orwGFBjpZlF7sn6jmGsl5OCWG1xG1l0fS8DgpuOMUHCisuhRk+xoYC?=
 =?us-ascii?Q?oVmrh9SFkCdPsbmBypgCXvu7cUG4Tghe3xivJYXA9U7RwmgFulQiQzKTR+Xi?=
 =?us-ascii?Q?0nrzmwXvTRet4NaL9N3qYs5b2RQw5KjG8u4p1mV+qDsEuiQj1cKmXsMBv3WB?=
 =?us-ascii?Q?KGDOSvjjXOHF8hfvAFdKQNiIIQW/owiwGqTY3MjlkKu4p6+mOqjMXHy2jo9O?=
 =?us-ascii?Q?qYxhSK+ey0CM2pUqOL1SoMyI3EGb+SOhBdiKmjvPel5bKEUbV31O9jSCa0Np?=
 =?us-ascii?Q?srtvD8i10ScfyYkgtQFPS/yrV7sDw+JMYJuYoDJknh1wntd22rJgS5TmHBsS?=
 =?us-ascii?Q?3NSDr0cE/D+vPRTTqO6qBwwx4RiDLr6FzC2sbo2dN+EEMIlXvC8GNW/72McU?=
 =?us-ascii?Q?/9yFHll78/AXJKICOzXrOJTdrwW+bpMWO6cETBBaGGoejDO9HpxPKi8xQOs7?=
 =?us-ascii?Q?23hm9A=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b72d88bc-7ff5-4be5-5238-08d9ec066117
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4531.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2022 19:57:19.5168
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BZybKaH9vNJblpYlIA85NoUrgmAykDCaAF/tAv1Rayl2jFRpMpfuv7fXUzci8fwCw05RFYl93juwvE/Vb3kJtVlbxhQHR6kqG+Zq3IO1lPY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB3721
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10253 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 bulkscore=0
 phishscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202090106
X-Proofpoint-GUID: m8WafNeUQONJrQ2nhoEJDFHYt92cftG-
X-Proofpoint-ORIG-GUID: m8WafNeUQONJrQ2nhoEJDFHYt92cftG-
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

When the kdump service is loaded, if a CPU or memory is hot
un/plugged, the crash elfcorehdr (for x86), which describes the CPUs
and memory in the system, must also be updated, else the resulting
vmcore is inaccurate (eg. missing either CPU context or memory
regions).

The current solution utilizes udev to initiate an unload-then-reload
of the kdump image (e. kernel, initrd, boot_params, puratory and
elfcorehdr) by the userspace kexec utility. In previous posts I have
outlined the significant performance problems related to offloading
this activity to userspace.

This patchset introduces a generic crash hot un/plug handler that
registers with the CPU and memory notifiers. Upon CPU or memory
changes, this generic handler is invoked and performs important
housekeeping, for example obtaining the appropriate lock, and then
invokes an architecture specific handler to do the appropriate
updates.

In the case of x86_64, the arch specific handler generates a new
elfcorehdr, and overwrites the old one in memory. No involvement
with userspace needed.

To realize the benefits/test this patchset, one must make a couple
of minor changes to userspace:

 - Disable the udev rule for updating kdump on hot un/plug changes
   Eg. on RHEL: rm -f /usr/lib/udev/rules.d/98-kexec.rules
   or other technique to neuter the rule.

 - Change to the kexec_file_load for loading the kdump kernel:
   Eg. on RHEL: in /usr/bin/kdumpctl, change to:
    standard_kexec_args="-p -d -s"
   which adds the -s to select kexec_file_load syscall.

This patchset supports kexec_load with a modified kexec userspace
utility, and a working changeset to the kexec userspace utility
is provided here (and to use, the above change to standard_kexec_args
would be, for example, to append --hotplug-size=262144 instead of -s).

 diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
 index 9826f6d..06adb7e 100644
 --- a/kexec/arch/i386/crashdump-x86.c
 +++ b/kexec/arch/i386/crashdump-x86.c
 @@ -48,6 +48,7 @@
  #include <x86/x86-linux.h>
  
  extern struct arch_options_t arch_options;
 +extern unsigned long long hotplug_size;
  
  static int get_kernel_page_offset(struct kexec_info *UNUSED(info),
  				  struct crash_elf_info *elf_info)
 @@ -975,6 +976,13 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
  	} else {
  		memsz = bufsz;
  	}
 +
 +    /* If hotplug support enabled, use that size */
 +    if (hotplug_size) {
 +        memsz = hotplug_size;
 +    }
 +
 +    info->elfcorehdr =
  	elfcorehdr = add_buffer(info, tmp, bufsz, memsz, align, min_base,
  							max_addr, -1);
  	dbgprintf("Created elf header segment at 0x%lx\n", elfcorehdr);
 diff --git a/kexec/kexec.c b/kexec/kexec.c
 index f63b36b..9569d9a 100644
 --- a/kexec/kexec.c
 +++ b/kexec/kexec.c
 @@ -58,6 +58,7 @@
  
  unsigned long long mem_min = 0;
  unsigned long long mem_max = ULONG_MAX;
 +unsigned long long hotplug_size = 0;
  static unsigned long kexec_flags = 0;
  /* Flags for kexec file (fd) based syscall */
  static unsigned long kexec_file_flags = 0;
 @@ -672,6 +673,12 @@ static void update_purgatory(struct kexec_info *info)
  		if (info->segment[i].mem == (void *)info->rhdr.rel_addr) {
  			continue;
  		}
 +        /* Don't include elfcorehdr in the checksum, if hotplug
 +         * support enabled.
 +         */
 +        if (hotplug_size && (info->segment[i].mem == (void *)info->elfcorehdr)) {
 +			continue;
 +		}
  		sha256_update(&ctx, info->segment[i].buf,
  			      info->segment[i].bufsz);
  		nullsz = info->segment[i].memsz - info->segment[i].bufsz;
 @@ -1504,6 +1511,17 @@ int main(int argc, char *argv[])
  		case OPT_PRINT_CKR_SIZE:
  			print_crashkernel_region_size();
  			return 0;
 +		case OPT_HOTPLUG_SIZE:
 +            /* Reserved the specified size for hotplug growth */
 +			hotplug_size = strtoul(optarg, &endptr, 0);
 +			if (*endptr) {
 +				fprintf(stderr,
 +					"Bad option value in --hotplug-size=%s\n",
 +					optarg);
 +				usage();
 +				return 1;
 +			}
 +			break;
  		default:
  			break;
  		}
 diff --git a/kexec/kexec.h b/kexec/kexec.h
 index 595dd68..b30dda4 100644
 --- a/kexec/kexec.h
 +++ b/kexec/kexec.h
 @@ -169,6 +169,7 @@ struct kexec_info {
  	int command_line_len;
  
  	int skip_checks;
 +    unsigned long elfcorehdr;
   };
  
  struct arch_map_entry {
 @@ -231,7 +232,8 @@ extern int file_types;
  #define OPT_PRINT_CKR_SIZE	262
  #define OPT_LOAD_LIVE_UPDATE	263
  #define OPT_EXEC_LIVE_UPDATE	264
 -#define OPT_MAX			265
 +#define OPT_HOTPLUG_SIZE	265
 +#define OPT_MAX			266
  #define KEXEC_OPTIONS \
  	{ "help",		0, 0, OPT_HELP }, \
  	{ "version",		0, 0, OPT_VERSION }, \
 @@ -258,6 +260,7 @@ extern int file_types;
  	{ "debug",		0, 0, OPT_DEBUG }, \
  	{ "status",		0, 0, OPT_STATUS }, \
  	{ "print-ckr-size",     0, 0, OPT_PRINT_CKR_SIZE }, \
 +	{ "hotplug-size",     2, 0, OPT_HOTPLUG_SIZE }, \
  
  #define KEXEC_OPT_STR "h?vdfixyluet:pscaS"
 

Regards,
eric
---
v4: 9feb2022
 - Refactored patches per Baoquan suggestsions.
 - A few corrections, per Baoquan.

v3: 10jan2022
 https://lkml.org/lkml/2022/1/10/1212
 - Rebasing per Baoquan He request.
 - Changed memory notifier per David Hildenbrand.
 - Providing example kexec userspace change in cover letter.

RFC v2: 7dec2021
 https://lkml.org/lkml/2021/12/7/1088
 - Acting upon Baoquan He suggestion of removing elfcorehdr from
   the purgatory list of segments, removed purgatory code from
   patchset, and it is signficiantly simpler now.

RFC v1: 18nov2021
 https://lkml.org/lkml/2021/11/18/845
 - working patchset demonstrating kernel handling of hotplug
   updates to x86 elfcorehdr for kexec_file_load

RFC: 14dec2020
 https://lkml.org/lkml/2020/12/14/532
 - proposed concept of allowing kernel to handle hotplug update
   of elfcorehdr
---

Eric DeVolder (10):
  crash: fix minor typo/bug in debug message
  crash hp: Introduce CRASH_HOTPLUG configuration options
  crash hp: definitions and prototype changes
  crash hp: prototype change for crash_prepare_elf64_headers
  crash hp: introduce helper functions un/map_crash_pages
  crash hp: generic crash hotplug support infrastructure
  crash hp: exclude elfcorehdr from the segment digest
  crash hp: exclude hot remove cpu from elfcorehdr notes
  crash hp: Add x86 crash hotplug support for kexec_file_load
  crash hp: Add x86 crash hotplug support for kexec_load

 arch/arm64/kernel/machine_kexec_file.c |   6 +-
 arch/powerpc/kexec/file_load_64.c      |   2 +-
 arch/x86/Kconfig                       |  26 +++++
 arch/x86/kernel/crash.c                | 123 ++++++++++++++++++++-
 include/linux/kexec.h                  |  23 +++-
 kernel/crash_core.c                    | 146 +++++++++++++++++++++++++
 kernel/kexec_file.c                    |  15 ++-
 7 files changed, 331 insertions(+), 10 deletions(-)

-- 
2.27.0