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 75309C5B543 for ; Sat, 7 Jun 2025 17:51:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD0696B008A; Sat, 7 Jun 2025 13:51:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D811D6B008C; Sat, 7 Jun 2025 13:51:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6DF86B0092; Sat, 7 Jun 2025 13:51:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A814C6B008A for ; Sat, 7 Jun 2025 13:51:27 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 26F9C142249 for ; Sat, 7 Jun 2025 17:51:27 +0000 (UTC) X-FDA: 83529346614.02.67C14E5 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf03.hostedemail.com (Postfix) with ESMTP id 479E32000C for ; Sat, 7 Jun 2025 17:51:25 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=mvvh8Sgq; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749318685; 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=5x7tqpY7FFQTqwJyBba7fEUnGOPyC2xMtgUC5Nr2hd8=; b=QmH/46FLUUfO1UWRmhpGNB43W8Sv5N/od7TU2WXmBLfJpLPahLKoCnxiMPnYpSyIpkN8go R29QdBexX8aPbGBy8x5Y/nl/4Rfwjl1uPItWeK7LY4lZzaUmiTXwPw5yDPcRB8R22Ua7s9 2+Qg7bSdyXT4TQXYVuQKPG3zvjtftYQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=mvvh8Sgq; dmarc=pass (policy=none) header.from=soleen.com; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749318685; a=rsa-sha256; cv=none; b=XFYhSnMf98pAEYp3JJnkXM1EhMfX+WjrzcocfbGIiUDB+Zkz0tsDOmBLoNkLjI+r7t9vxC 6x7kgdXHv9vO8JJ9bqGbHkHZhLwVLtcgVSgyUboOxKBtHMthDfubDQOBeZaLRbZrc+ZCez WDCPS54G9r0lztjh6iGZDELMzXL6V1k= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4a6f6d52af7so2882021cf.1 for ; Sat, 07 Jun 2025 10:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1749318684; x=1749923484; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5x7tqpY7FFQTqwJyBba7fEUnGOPyC2xMtgUC5Nr2hd8=; b=mvvh8SgqJyjQ4Wqt8vlynxY1jsfl2yl4TjL9dz8EmF/6Rni7n+Tx/iKhxQcvkt2AyO BGSoz+6fsKnoCus5oKt07Ycu6+fl6M+hD+jWaVWVuhivPrFovPdahjaV7w3a4EUbBDpp iDmDBncIBkXlnOkxXZO/VWl3+qIcbGO9sWwus6JzbXWSAXEAmaPQQokAqQm56xHPYr+N vdJnR9RgeL18/5tLbzZFi2BRwUUUlwTIm+cgXxdDUFBFtECn4x8qC1xEfsOK38f5IhCF 57RwQlnK/yxmvSb5kfkkcj/pVCLtK2TkrTSmKWKwwMBr/E9Zi82UzsP5NeLZtb5HrTZZ iWZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749318684; x=1749923484; 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=5x7tqpY7FFQTqwJyBba7fEUnGOPyC2xMtgUC5Nr2hd8=; b=bwOWFpT3wPydbWyuuIwUNhzEUkMgPOTJAtOFcYrq40G93sLACzu3c9q+ZJ+r7Q1cWD FsT1q8Hd09ImP/YOd3+dFn781Q/xwC6GzPwd0dwIh6cZP00ZyXv4N9hHI4NNHXLnmRD5 QpYIsIV3GZQAOn4ZaNM6cDZIsoBATqlxsuCjD6X2DoWi7Gdi+Q93oWAIcm/ogJQWWfA3 KnoQwFvSZvpginvWuaV+8V/isKh3xee6GDrUsc4AvuLTltjLmQ2tbSJyzywH5p06DoyR VLyGrbi20nf/FKvfb7QVgivbbX1dOSi6J26vLGh1AQzjhWhnULY1EJlYlT03qgJSXEIv boFw== X-Forwarded-Encrypted: i=1; AJvYcCXNVzubI3J5Gi7eXUNuPCXPyvNT9PYa5cweDLpV1GS1u0yRV8PHNGZ7T4hIQqdkzidBKUvSm8VzWA==@kvack.org X-Gm-Message-State: AOJu0YwddPsbfBhfos2QaXVZxdPUPa9dU7UWnrjd8bFHVRJGyZix+U39 l78560wu5E8YTZl4c0q2Cq9UgbXng/1NoQBvujBFDSkIBWz2WTXQZQSVvuK5YEw/9lG/t51luUb r7L4RwA1/KW1JKR8KH+MHD3AAuNjXT3DQLs0CZLrCIA== X-Gm-Gg: ASbGncurv9dqoiVv/8nFkizNNzrUZ72ZUKZA17jJBXBwwaxx/M0cE3WSOtRgxb0qz6N 50pb8lJh9FszfFbCkK04ZP0v6edj4Li20CLZwNrYmIuiufka+W0Yr8tcUrtAVUZAr6bsTKJfSX+ JHJqRF4ND64VAXa/wNv47oJCtcDtLNFQ== X-Google-Smtp-Source: AGHT+IEFn03IT5C9pJFdS9tKXW+5B//fadk0OraiYcKgA8zAKYeMYRVrgrdQO/iYtEedwVrjla+0YNmycwBcp+tbU+w= X-Received: by 2002:a05:622a:59c6:b0:494:aa40:b0c3 with SMTP id d75a77b69052e-4a5b9a0546bmr105143941cf.10.1749318684345; Sat, 07 Jun 2025 10:51:24 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-6-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Sat, 7 Jun 2025 13:50:47 -0400 X-Gm-Features: AX0GCFucvwsWUVtQaH9FvUCH6_T_TwPU1EcsbQ3OjZROJgpiTAuxkweKotJ6ncQ Message-ID: Subject: Re: [RFC v2 05/16] luo: luo_core: integrate with KHO To: Mike Rapoport Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com, changyuanl@google.com, dmatlack@google.com, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, zhangguopeng@kylinos.cn, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com, ptyadav@amazon.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 479E32000C X-Stat-Signature: ebrmpjaa9xf5b9re1a9yu1kk7e4ud4r6 X-Rspam-User: X-HE-Tag: 1749318685-271945 X-HE-Meta: U2FsdGVkX19b3bf+4+yfvvASiliR7Lu+8nMI6PI5+q2vC53BysPzQmeqfPXMDi5ISM2H/GRkAihszLxaFpBsUALJUrq/98YbEZ0jCIACfDNowtX9QgKMZYjI6Xe4GFMcW/rwGozGPEAIY0f/UjoEpH2mGgJLEe4B3L/SqdYRn8yHcZPM9N+AfMnlHwgO3+Pn9lyXNqAKX8iaH1WJ3yNI3Yr6eSAbdXVZaxJ0+cURgDAu4aPgKNmkz6/UcnsqhOwipQXYLYCHQ89GmFugsg0nL1snMq6FeU2uD9jny8bYwi1b3mt1F28MYX8ry+eX2tUOr0N6ROeQchWwfx/rytgQFlWun97fYmXwF+nCYgVYQmdBP0vX+CS/x/FTYVfPJFpW1E3UNXbG/DVx9r5XjIxXyGAFS+o6SXVBmeUH6e2vM9Ueaa30DROcg57/XeiQwF/QIygD21gI5r+roqq4REOtzv11HZbZzNuRppvKV00SgKqqQ/lu7UXDQ8iRnGbTEF1XJ0IS65wR9lpk5LxKAbykQkNxiYjT0Clo6OMgjCMlsGsSPpfBQ0QbGF3rT2mskFvEYWWoZNbE2lhf5WveemT77Vm1Z1cMae7B1bJumuXiiJzFGaVRVzeTwxBGO2QRGi1M3Id4jAiOwutj/3LtnZ0ls/5AirpxVjWSfCinb9PY6l1YQsgheBTRLASa5O40qFdxE2o9qx0JBNMd3qJV4t6BN66Y/9el4x9vr6bgHQhGekj7yULtJ0iqh9X/LhmGmhCBhoR8x99DSDezNVOFAPuNcX2U3YNAQR4YiOiUPKc5kV2yb4uLOM944QFz0dNpYcTDoN8DuS8iXfEFC1LO+7hvKAPCHN77S/b9lE15r4SsIi4h8NJDpxv8PJaF+CgCpdsFY+xeTl1u7ZlGadryqEbG/z/MlHCVLMjUbUisFfOVfwmSwYdDlrUJvSJYX+7RxE3A/oAchzA8oWDJF2Qeab/ kkN7u+3n XRKTPOdc7g9ArVFvf6yKZ2D9UP/UZxLkGt/h1RUjSUeHmNJ5wUhnDS1vlYUxm5i8Njj2jmgUOEWj5hWqMnrEprRJGizRltmiJyxjMsS2D0WiuJvy8c5a1OOERWnPjC4TXYDVjZSFh2qK3CAXsX5PQ2mRv/zsSiLLuK0uCZvHGLgd9vZvswli4rjdmr+5KIeXULr4P+pDCErmxepJriHAC1FWKqwTKj8QgqeI3bS8OnQt7Ts0sMSFyrAB/mu1RoogSoiAT/BTsgp8I/B7vofwdISk3FHQuRxQrU8pacOt3R/piVH8dD6oc1+NiehdwMAqhkUBzg3TS4KeZM+jHFlovK2Hra6qd3TsG8FF8JbjQnhkMED6N5I7/hIvBT+PqCucY26PxUGMKs5mp5107g37MSt2eFp8iRa6n0+/2cNFPMowDStbyXt70bs3gVNW8aB3CROXG8qDRn2QUDBo= 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, May 26, 2025 at 3:19=E2=80=AFAM Mike Rapoport wro= te: > > On Thu, May 15, 2025 at 06:23:09PM +0000, Pasha Tatashin wrote: > > Integrate the LUO with the KHO framework to enable passing LUO state > > across a kexec reboot. > > > > This patch introduces the following changes: > > - During the KHO finalization phase allocate FDT blob. > > - Populate this FDT with a LUO compatibility string ("luo-v1") and the > > current LUO state (`luo_state`). > > - Implement a KHO notifier > > Would be nice to have more details about how LUO interacts with KHO, like > how LUO states correspond to the state of KHO, what may trigger > corresponding state transitions etc. Updated. > > > LUO now depends on `CONFIG_KEXEC_HANDOVER`. The core state transition > > logic (`luo_do_*_calls`) remains unimplemented in this patch. > > > > Signed-off-by: Pasha Tatashin > > --- > > drivers/misc/liveupdate/luo_core.c | 222 ++++++++++++++++++++++++++++- > > 1 file changed, 219 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/misc/liveupdate/luo_core.c b/drivers/misc/liveupda= te/luo_core.c > > index 919c37b0b4d1..a76e886bc3b1 100644 > > --- a/drivers/misc/liveupdate/luo_core.c > > +++ b/drivers/misc/liveupdate/luo_core.c > > @@ -36,9 +36,12 @@ > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > #include > > +#include > > #include > > +#include > > #include > > #include > > +#include > > #include > > #include "luo_internal.h" > > > > @@ -55,6 +58,12 @@ const char *const luo_state_str[] =3D { > > > > bool luo_enabled; > > > > +static void *luo_fdt_out; > > +static void *luo_fdt_in; > > +#define LUO_FDT_SIZE SZ_1M > > Does LUO really need that much? Not, really, but I am keeping it simple in this patch. I added the following comment: /* * The LUO FDT size depends on the number of participating subsystems, * preserved file descriptors, and devices. While the total size could be * calculated precisely during the "prepare" phase, it would require * iterating through all participants twice: once to calculate the required * size, and a second time to actually preserve the data and populate the F= DT. * * Given that each participant stores only a small amount of metadata * (e.g., an 8-byte payload or pointer) directly in the LUO FDT, and that * this FDT is used only during the relatively short kexec transition * period (including the blackout window and early boot of the next kernel)= , * a fixed size is used for simplicity. * * The current fixed size (1M) is large enough to handle reasonable number = of * preserved entities. If this size ever becomes insufficient, it can eithe= r be * increased, or a dynamic size calculation mechanism could be implemented = in * the future. */ Pasha