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 A9B90C36002 for ; Tue, 25 Mar 2025 03:06:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BEFD280003; Mon, 24 Mar 2025 23:06:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76B9E280001; Mon, 24 Mar 2025 23:06:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60CE0280003; Mon, 24 Mar 2025 23:06:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 43F04280001 for ; Mon, 24 Mar 2025 23:06:51 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6D780141111 for ; Tue, 25 Mar 2025 03:06:51 +0000 (UTC) X-FDA: 83258586222.01.24540BD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 0E4FEC0005 for ; Tue, 25 Mar 2025 03:06:48 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="gt/DY1J/"; spf=pass (imf22.hostedemail.com: domain of ruyang@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ruyang@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742872009; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8QX+zFdWjeuQlzuCcAZM/kErn+a5XVCQ6Ck8ssaU/og=; b=OrA6uHpnjywDVTcfUAgxavNBCmA0ddLP9Y/tHfiKESYBkDK1fcxmNqwwKis4VFKMgBzSeM I0f0miRPWdA9b52pIcVy4bju8a2WjB25jT1DSJx84iKZe7JGnWh9PMIFW8G3fkH4C2Z4g+ Ib64fbtRGYlTieW6vAr8hRGYGiGc9rw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="gt/DY1J/"; spf=pass (imf22.hostedemail.com: domain of ruyang@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ruyang@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742872009; a=rsa-sha256; cv=none; b=3p/XzwscAQL1WwJHr94MfPopacPCAw1y8kjh2Db/rBpCi6+o+/4mr6HdupJykIVON9yWAR 7CNPFM8gqYBwxRDXxWkgSD54aEgtHE6T2aroulnNpjJDp+EUYSzKXylXQkad8X3Qvleh5a /xCCGtcksuw6EgpKQudb6banFhnUhaQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742872008; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8QX+zFdWjeuQlzuCcAZM/kErn+a5XVCQ6Ck8ssaU/og=; b=gt/DY1J/08YJGkLPSbtFsj9R0wa9fKrpv0qFhOS8BcAQTTB+X7Wy+jG+mVWQ1vMk4yrREM ZiH3R+YzkRLR9m9doV7s1JZsBY85LNv/o6pLKGyiTEx2Exp1aluntf5+ihk8Y6OuwmzG8v 29RgOsYkL7AjGDiqBAM+q01qch4kb1w= Received: from mail-io1-f69.google.com (mail-io1-f69.google.com [209.85.166.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-9I2EfWGENHGlrbRFwxP8dQ-1; Mon, 24 Mar 2025 23:06:46 -0400 X-MC-Unique: 9I2EfWGENHGlrbRFwxP8dQ-1 X-Mimecast-MFC-AGG-ID: 9I2EfWGENHGlrbRFwxP8dQ_1742872006 Received: by mail-io1-f69.google.com with SMTP id ca18e2360f4ac-85e0c6b90e0so915784039f.0 for ; Mon, 24 Mar 2025 20:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742872006; x=1743476806; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8QX+zFdWjeuQlzuCcAZM/kErn+a5XVCQ6Ck8ssaU/og=; b=UxaMUbbkWiLTgrKy5wANnSzj+o48HEAIHSIkGXamD6cF8zbJhU5Eb1Fhy0r2kQe19s blzaKSXi+wDArYpll49ePm+ubsIsseB9P8kaw6rAQugYjElqIyhRJhXgNO6xylOdUlIS jhmYMO3856jUviCJUmne3bOIklL4c3dDKksIBkSPCFrIK46g7Y039tCyTzRF0mdZAE+c 2EZ6ETZlyMET724DhZ+8xFsr+GYk04msxLEi+FvJIIhUY7UHGgRBUxSgrpArff1QVvnK bg8PEt+rSyd2qmPJL70+b6dyNDOsBbx6A7jGtnzMYeY26SAKNXOWJUr0WSP34i3kD39X jLIw== X-Forwarded-Encrypted: i=1; AJvYcCUjvP5T5Tp49/7QNOH7UYlyyku6vopibI99+jGiN0HnRUWN47iiPb5+skQIc6DFSQUDqK1T4LpBOQ==@kvack.org X-Gm-Message-State: AOJu0YxnF7dMcR4aMrzBcSu2nWypKe/TCgUp8tyMeHfyshNCToCiDkBl 9tWQXiMplcxvGx4B5KFhDEduOpUt9Khi+FqGZD/V4n1sP3YiXDT4JvtVeNh14VwaXopI2y8tIYm 2eleSo8ZQ0xvO0Q+4kTpZXN/yzgkiv9b76MugqLhb+hDmjwX6tdgoiVCksO4U33MrH1jMwgfhDk niJI5AJWn7IdAqLIU6Kq3D254= X-Gm-Gg: ASbGncvrUNMYmHEIMaLVaznfOl05DdrR2W0NleXGWKSswHpCzXMHP2hQ2026VQHstNO W8i+dg8cxJTBTb/Th0uXNLwl5Wb7x3rdkf4KUssjCOkWr4YBHKe0FnUZuyDUZOJ+FXtV8CN9I/Q == X-Received: by 2002:a05:6e02:748:b0:3d4:6e2f:b493 with SMTP id e9e14a558f8ab-3d59615d9b2mr153651405ab.11.1742872006028; Mon, 24 Mar 2025 20:06:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE5XTfTYA1qkf4MGjSh6Evza+A2MB/jUqh1YG/uG3OXh4qzNNvGTBc1K4PgXO/eVmwdqOvHcPKX5AjVSKaQhLs= X-Received: by 2002:a05:6e02:748:b0:3d4:6e2f:b493 with SMTP id e9e14a558f8ab-3d59615d9b2mr153650885ab.11.1742872005537; Mon, 24 Mar 2025 20:06:45 -0700 (PDT) MIME-Version: 1.0 References: <20250320015551.2157511-1-changyuanl@google.com> <20250320015551.2157511-12-changyuanl@google.com> In-Reply-To: From: Dave Young Date: Tue, 25 Mar 2025 11:07:06 +0800 X-Gm-Features: AQ5f1JodZdPjZPmn7C-4IUrPojZILVca8awRM4MpIz-0KIylSAlKoZUHH0RUnGg Message-ID: Subject: Re: [PATCH v5 11/16] kexec: add config option for KHO To: Pasha Tatashin Cc: Changyuan Lyu , linux-kernel@vger.kernel.org, graf@amazon.com, akpm@linux-foundation.org, luto@kernel.org, anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, ebiederm@xmission.com, mingo@redhat.com, jgowans@amazon.com, corbet@lwn.net, krzk@kernel.org, rppt@kernel.org, mark.rutland@arm.com, pbonzini@redhat.com, hpa@zytor.com, peterz@infradead.org, ptyadav@amazon.de, robh+dt@kernel.org, robh@kernel.org, saravanak@google.com, skinsburskii@linux.microsoft.com, rostedt@goodmis.org, tglx@linutronix.de, thomas.lendacky@amd.com, usama.arif@bytedance.com, will@kernel.org, devicetree@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ziD8KoNBJsvLPungiS_2ciw3ldybnAT7t_MJCSH7AYs_1742872006 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0E4FEC0005 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ar3stu7yf9e84jsk8t56tafb6f6gei5t X-HE-Tag: 1742872008-687591 X-HE-Meta: U2FsdGVkX18mj7GQm2VYszBNcQCIqRzr7hDqQsDU5UulAEqqxgGCdEdNsFqyQyEIEVk90x9/5iCSvkyAFeOrH2z9EOeKzQBa8usPUHZhVNHi1FBfrmjs6oVslNg8PBZNVQUaz9ulNYwRa6b/urgLCus5TX+U9oOiSsnR+q1vmh4dU/opyf8h5t0qUpX82tY5hTB+oJ39CDcJbGHJo/adhSMGNytEc6Ks3G2PrezhnRx5jjKmwybYpKVjOQFzdtW8ki2+KrEuYx0URmenZzBURqlhUgPLLLu3n2+XRI/EBq0Ey4PNihe2mnNy3oXokCmsEnxdXrxxigzrFhE4QkPyQTF/EbvauaKQynJ7G0h4TaR8J6NhNNVwEXXEOIK9TOd2j46yC43qvUuWy+mKtvb2zijYdzMilQTEWpKKtKiiHieTgNYA7znGtHZnSk1FCPLpz0WfULXODj0sY+Bhdv/IMqXFiW462Puqwk0FOrY65tDLdwbmBp7ez0o1Tbe+1AKVI3GL5/BWVCO3f3nJOMsx5OQ9ntTHUhPsQ27g3J+66sg6rfwyXqHAvDVNkHyRJKuAU14QcYwn5rDkpDxxTgxF/GGr0cuBxU1QM1MGnQpMC9tdwd8zPDvJVBTpEuSNEqXEtOc+a4Tg6LxkgRzjfDa6AMOUhTgxTpbKQ6u+cGU2+dM6E8t4RqayEfitX7r8PmA8y01rmt+L7DEePRDGTdWZqMTcWu+tkYYXmc72YweDJmLig8iCcmvWfb3fZMv0VNQaEVAgvqqXMQE+GN9BhvDTH8JC0UMnRqtOKcgEDFicTzEwsOatT7NdK1hj9iZOJIz+2wWSWbXOb2Kf21JXZhr7Sjo7sI6eS5pMiXp4iQPs5FpUBSj4TwDXj2wkXjrh6w8CRpZASlBTJ2YniZm1jDmRPpr01KsoR/Da6/ie4xKn7CEswZYbB9n1nDMeEKR+FE1o/09HIH/Al7FePt4/65E iWtYywg0 dJbvNoFE7MObjOKaupYYp5ddGkjnKA182lcwczQjfkDwh55qHWMC2griaQkndS9S2fmbgRq3razMKOcILv3eq2Z8HXYJEARyMiCvOZKyRLUVxe/sMmd3lZwkut7/CpTK2K0u5KzqE4YyRk5SD8sBWDcMj62nGJDWFtFqlTpAVNjo8yt7hFN3eBF5YhW3VxTTsxB0u78ejOxteGeGw4EKqxntuKasAPwqg8gKiSczNFclvXgtlibia760w1wTVGQr66TQo3J6aDHbSuGvmlJl0zknL89CnKihH3wR6bx6VYWdpyrViacX7CXBW1gVkhAn4Go3DEEPwT0MkABgrsb5hZ1Ppp2ffIBhSx0KExBttpgmybxGyBOq0CWe5BCd38kDFu4+zXKVqNYLWfNK9WVU6vGGXvSbi2qQEW7wwQxaQE58seyrZ1KbbGtJ/cIaTVWM0oAOIf7UhOP8a/0leqH7+x028oliSm1Jh2sM41yMVXDPmoQGI/aphhy3SYbB+zf812vBOkt0OkGI63Jm0LQsY68qMwcNgOloZuhtvPkOcLfO/QgSNSdKBkrQPAjojuCU3snI0q7jd+5T3/mSCCrLyAeD4tH0W1imu2exz+ngHt5vV//s= 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 Tue, 25 Mar 2025 at 09:24, Dave Young wrote: > > On Tue, 25 Mar 2025 at 03:27, Pasha Tatashin = wrote: > > > > On Mon, Mar 24, 2025 at 12:18=E2=80=AFAM Dave Young = wrote: > > > > > > On Thu, 20 Mar 2025 at 23:05, Changyuan Lyu w= rote: > > > > > > > > From: Alexander Graf > > > > > > > > We have all generic code in place now to support Kexec with KHO. Th= is > > > > patch adds a config option that depends on architecture support to > > > > enable KHO support. > > > > > > > > Signed-off-by: Alexander Graf > > > > Co-developed-by: Mike Rapoport (Microsoft) > > > > Signed-off-by: Mike Rapoport (Microsoft) > > > > Co-developed-by: Changyuan Lyu > > > > Signed-off-by: Changyuan Lyu > > > > --- > > > > kernel/Kconfig.kexec | 15 +++++++++++++++ > > > > 1 file changed, 15 insertions(+) > > > > > > > > diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec > > > > index 4d111f871951..57db99e758a8 100644 > > > > --- a/kernel/Kconfig.kexec > > > > +++ b/kernel/Kconfig.kexec > > > > @@ -95,6 +95,21 @@ config KEXEC_JUMP > > > > Jump between original kernel and kexeced kernel and invok= e > > > > code in physical address mode via KEXEC > > > > > > > > +config KEXEC_HANDOVER > > > > + bool "kexec handover" > > > > + depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KE= XEC_FILE > > > > + select MEMBLOCK_KHO_SCRATCH > > > > + select KEXEC_FILE > > > > + select DEBUG_FS > > > > + select LIBFDT > > > > + select CMA > > > > + select XXHASH > > > > + help > > > > + Allow kexec to hand over state across kernels by generati= ng and > > > > + passing additional metadata to the target kernel. This is= useful > > > > + to keep data or state alive across the kexec. For this to= work, > > > > + both source and target kernels need to have this option e= nabled. > > > > + > > > > > > Have you tested kdump? In my mind there are two issues, one is with > > > CMA enabled, it could cause kdump crashkernel memory reservation > > > failures more often due to the fragmented low memory. Secondly, in > > > > As I understand cma low memory scratch reservation is needed only to > > support some legacy pci devices that cannot use the full 64-bit space. > > If so, I am not sure if KHO needs to be supported on machines with > > such devices. However, even if we keep it, it should really be small, > > so I would not expect that to be a problem for crash kernel memory > > reservation. > > It is not easy to estimate how much of the KHO reserved memory is > needed. I assume this as a mechanism for all different users, it is > not predictable. Also it is not only about the size, but also it > makes the memory fragmented. > > > > > > kdump kernel dump the crazy scratch memory in vmcore is not very > > > meaningful. Otherwise I suspect this is not tested under kdump. If > > > so please disable this option for kdump. > > > > The scratch memory will appear as regular CMA in the vmcore. The crash > > kernel can be kexec loaded only from userland, long after the scratch > > memory is converted to CMA. > > Depending on the reserved size, if big enough it should be excluded in > vmcore dumping. > Otherwise if it is a kdump kernel it should skip the handling of the > KHO passed previous old states. If you do not want to make the KHO conflicts with kdump, then the above should be handled and well tested. And then leave to end user and distribution to determine if they want the both enabled considering the risk of crashkernel reservation failure. > > > > > Pasha > >