From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C229C369DC for ; Tue, 29 Apr 2025 15:53:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 507FD6B000C; Tue, 29 Apr 2025 11:53:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DF936B000D; Tue, 29 Apr 2025 11:53:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 381726B000E; Tue, 29 Apr 2025 11:53:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1832B6B000C for ; Tue, 29 Apr 2025 11:53:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A4F4E1208E2 for ; Tue, 29 Apr 2025 15:53:33 +0000 (UTC) X-FDA: 83387526306.05.1B31A71 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf24.hostedemail.com (Postfix) with ESMTP id 10576180004 for ; Tue, 29 Apr 2025 15:53:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bodHUhFW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745942012; a=rsa-sha256; cv=none; b=xZz64mUfhH/H1PR9WF/eTEbPz93JOifDvU+S+1OKqnFPiEDJivfpINpdMu52foeiv+FfGB bu7QGtAoAB8X5bSypKIaYprqwwGDsPafCaamqG+i8tQ9rgcrizcMVSTkHy/hh6Lg1ayN9V pOuv7YJVAh8QleIJyYy5POv6iScL92w= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bodHUhFW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf24.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745942012; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gIQY7xEXbpYM2GrulPmRHIyp5dF9trP+hXYQZJ+rf2g=; b=ukB/MJFIwKBKhqzsE9SPD4hc6C4AVTn0E+m4yugCQQ++sPXFQMlxH7fKFjpb10LYXAl6u9 Jc8qQOUdU439mzkiDY1BLz1aJ1EUX61ix9QVGcRZNLajAueYyqbr5K341GI8hLRa6xAci/ z7vpirofZCiQUf6idsq1ubPzIRY51f8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 3081461567; Tue, 29 Apr 2025 15:53:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FF31C4CEE3; Tue, 29 Apr 2025 15:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745942011; bh=KUMxrCWS4kHpmdAy9k+WvcFlk1e7OoIGE+mnAbwsrzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bodHUhFWmP8Sz+DwztlGIKQ3DTG0NltdGnsHe7ni+bUP6fEyz2VjB5G4/RO632uxl Ok5eMkAxLDy3ES9iw89J6qsDeCiVWLbFAOl4I7iIfYFK1owb91ueyY3AfuR298JbVI jqUuik7hggNabBfGbkajNmHQQFzZBlSs8lHBfO7Pva49NvgOzont8BnXeZz/tZJqXY ajwCCZIduCGd8lSj7mGgCYRo7ELlsZHcloWt+J+CGNmMn65WUlzciIyiX49vYjsa1A sPAaL+CJ+s/g9wScEi5TRBzemcEql28oquwj8CODrTxymcg1tAYr9dgbCkX0CQU3qz htosilAwBJ0Dg== Date: Tue, 29 Apr 2025 18:53:15 +0300 From: Mike Rapoport To: Dave Hansen Cc: Changyuan Lyu , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com, corbet@lwn.net, dave.hansen@linux.intel.com, devicetree@vger.kernel.org, dwmw2@infradead.org, ebiederm@xmission.com, graf@amazon.com, hpa@zytor.com, jgowans@amazon.com, kexec@lists.infradead.org, krzk@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, mark.rutland@arm.com, mingo@redhat.com, pasha.tatashin@soleen.com, pbonzini@redhat.com, peterz@infradead.org, ptyadav@amazon.de, robh@kernel.org, rostedt@goodmis.org, saravanak@google.com, skinsburskii@linux.microsoft.com, tglx@linutronix.de, thomas.lendacky@amd.com, will@kernel.org, x86@kernel.org Subject: Re: [PATCH v6 11/14] x86: add KHO support Message-ID: References: <20250411053745.1817356-1-changyuanl@google.com> <20250411053745.1817356-12-changyuanl@google.com> <35c58191-f774-40cf-8d66-d1e2aaf11a62@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35c58191-f774-40cf-8d66-d1e2aaf11a62@intel.com> X-Rspam-User: X-Rspamd-Queue-Id: 10576180004 X-Rspamd-Server: rspam04 X-Stat-Signature: qc5u7i3nocdwsmndy8ht1zbyr9m155uf X-HE-Tag: 1745942011-556882 X-HE-Meta: U2FsdGVkX1+Mr4HQQNUs/6zvcivaiE0QA8DCJvd6IIfJ0Jjgpm1aqd8jxPufCSWIelkaU8dGBRoTvLDYPJNHkUWtN4DWtdNuav7tN7t7YgpeV5fraUOIWS8N6UUSlaPR43hXXbYlUxyUGs9kJ1AMJsE2LyFdu8BanmSzZxM4z0gd58p0fxfrFmLtt1bv5VRO/NgOYzbHwu+TLXM2doNqWae7lR2HXVJZwae4eJbhcXAbn8gJY2P0AfyJNDTflF1M5VQZOQ8O2JMa7itPgeiYrAOoidwwo4Z1Q1g3cTUMFaAWNSa9cNnXs8Xyfd0ripYkiBbTJYKG7C0T/SfJy2VBUgAVOfzN68uSmfgpfojSpBTm2wa/paObmtcpRUExjqTxVDwE6UkkMzDArA6j8odWOEYxswXD2iG0T09rp98KMwi2Qts/pjMbAow4RZt4gVs08ep2eCzTIESe+d+bHQMLDlZsMacFBBJuYGRtMY+uyq/pj4lIko2hL/wPpXeQi1OIYc9QpjgdhXvJ7v1XauHfX2B1re+GSF8DqoElNXgdw/Nl0P5hAmM62/EzVgL3qjU3gP7hAYmJkqPyD/Wedb4vWNpH9LiFE2fGJ32eEZBSEGJl+mWkzD1Sy6G8UR/1wk0iEiJhOtxPNs+AqaOPgPMN/krr0cZssntU2G485efpBNWnZ719rMOSy3iEVvt4ZFcuJ4VH0lNCISQINOr3+XfhazACWYjOfOUn+q18Fr19kznCQ7zsOw4TsQYnCxc5AMMHyIGz/K8Ip2TleofZBQrVN4J8lcD7c5Z/PfyzvmVez4ktriIReG+azboh3Fnf8CzYpL3/deObjFAwOIp/LdogocZOmbFMtwPaRmsh9QTbszSX0zn9rKSpEnuzSuhyfzOPrpTCPJ/H/jFKMeMGlfReE96YBB7gEll26RVmBINAsAygk+zkLW4LC5m4W22JFjChj6eWFmWaEJafSHrjCrN ACStmr7I s2UWfLUqtjhXnVBZwoZ2qNLkCBeExtxE1AEGMtft0uYkLps+JLhgp6rC1QM89DKpGB3aaZgRswAuckjulJ8nzeM7y6cw30Wc/XJc9E8k3cHYGzk/n79Hur4WGIBHYrfxya2eQS2ont3zWFoH9tVBgHniWIer+X8z6a853KhOJhy05Ogg9FLNPJnlN2HJnV/BZkwY6giqG3vRbJl6YUoi37HSrYZurHQMxypW+h536KH/LdNr6LVmRkEqEehbRapVKFJ3PeGyTEUm8gUbzWj5j6Am91w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Apr 28, 2025 at 03:05:55PM -0700, Dave Hansen wrote: > On 4/10/25 22:37, Changyuan Lyu wrote: > > From: Alexander Graf > > > > +#ifdef CONFIG_KEXEC_HANDOVER > > +static bool process_kho_entries(unsigned long minimum, unsigned long image_size) > > +{ > > + struct kho_scratch *kho_scratch; > > + struct setup_data *ptr; > > + int i, nr_areas = 0; > > Do these really need actual #ifdefs or will a nice IS_ENABLED() check > work instead? > > > + ptr = (struct setup_data *)(unsigned long)boot_params_ptr->hdr.setup_data; > > What's with the double cast? The double cast is required for this to be compiled on 32 bits (just like in mem_avoid_overlap). The setup_data is all u64 and to cast it to a pointer on 32 bit it has to go via unsigned long. If we keep actual #ifdef we can drop the double cast because KHO depends on CONFIG_KEXEC_FILE which is only enabled for 64 bits. > > diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c > > index 68530fad05f74..518635cc0876c 100644 > > --- a/arch/x86/kernel/kexec-bzimage64.c > > +++ b/arch/x86/kernel/kexec-bzimage64.c > > @@ -233,6 +233,31 @@ setup_ima_state(const struct kimage *image, struct boot_params *params, > > #endif /* CONFIG_IMA_KEXEC */ > > } > > > > +static void setup_kho(const struct kimage *image, struct boot_params *params, > > + unsigned long params_load_addr, > > + unsigned int setup_data_offset) > > +{ > > +#ifdef CONFIG_KEXEC_HANDOVER > > Can this #ifdef be replaced with IS_ENABLED()? The KHO structures in kexec image are under #ifdef, so it won't compile with IS_ENABLED(). > > @@ -312,6 +337,13 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params, > > sizeof(struct ima_setup_data); > > } > > > > + if (IS_ENABLED(CONFIG_KEXEC_HANDOVER)) { > > + /* Setup space to store preservation metadata */ > > + setup_kho(image, params, params_load_addr, setup_data_offset); > > + setup_data_offset += sizeof(struct setup_data) + > > + sizeof(struct kho_data); > > + } > > This is a bit weird that it needs this IS_ENABLED() check and the > earlier #ifdef. But I guess it's following the IMA_KEXEC code's pattern > at least. And with other #ifdefs as well :) if (IS_ENABLED()) can be dropped here, but having it makes things more explicit IMHO. > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 766176c4f5ee8..496dae89cf95d 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -451,6 +451,28 @@ int __init ima_get_kexec_buffer(void **addr, size_t *size) > > } > > #endif > > > > +static void __init add_kho(u64 phys_addr, u32 data_len) > > +{ > > +#ifdef CONFIG_KEXEC_HANDOVER > > + struct kho_data *kho; > > + u64 addr = phys_addr + sizeof(struct setup_data); > > + u64 size = data_len - sizeof(struct setup_data); > > + > > + kho = early_memremap(addr, size); > > + if (!kho) { > > + pr_warn("setup: failed to memremap kho data (0x%llx, 0x%llx)\n", > > + addr, size); > > + return; > > + } > > + > > + kho_populate(kho->fdt_addr, kho->fdt_size, kho->scratch_addr, kho->scratch_size); > > + > > + early_memunmap(kho, size); > > +#else > > + pr_warn("Passed KHO data, but CONFIG_KEXEC_HANDOVER not set. Ignoring.\n"); > > +#endif > > +} > > Please axe the #ifdef in the .c file if at all possible, just like the > others. This one follows IMA, but it's easy to make it IS_ENABLED(). It's really up to x86 folks preference. -- Sincerely yours, Mike.