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 6D35CC282EC for ; Tue, 11 Mar 2025 12:19:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A258280004; Tue, 11 Mar 2025 08:19:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 37C73280001; Tue, 11 Mar 2025 08:19:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17EDE280004; Tue, 11 Mar 2025 08:19:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EA5F6280001 for ; Tue, 11 Mar 2025 08:19:17 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 23125161EBE for ; Tue, 11 Mar 2025 12:19:19 +0000 (UTC) X-FDA: 83209175238.02.4D357E3 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf15.hostedemail.com (Postfix) with ESMTP id 33614A000A for ; Tue, 11 Mar 2025 12:19:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cLJwnHpB; spf=pass (imf15.hostedemail.com: domain of ryabinin.a.a@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=ryabinin.a.a@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741695557; 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=uMdqx5IAy5RwkV48z9EOvdZc6wlr4q4CS/HOkuwTfFI=; b=2BXoNcoHhLSXWC7qgKoHwKRl4Z1B+6lat4LRjP11+DM/jnrEV/yFE4CE01hOp0kRje/iMv aTPDHhn8JVIw/ZJFdDG/ndkM8ulHF3rDNIZeWbBWPeJTCRG4zUCEoi3EQdFx50Zof5RURn He4b/NxncUs0FN7zPxe2nPH94nVI/PM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741695557; a=rsa-sha256; cv=none; b=7oSb4xsPMlz3Yi9PVLP8tuar8kZoKvO/SCehcBdkXemU7bT5AeRaO8q4yWPCznndzDtYFc G1EipmFsaX1bEtsBGprRgRQt39sXuogRsqoQmP6aI68lhZdaiGWsEOGIQbL9GR8RYLth2M xtp30M3lh38NrLvEj11DfRKNku5W/FA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cLJwnHpB; spf=pass (imf15.hostedemail.com: domain of ryabinin.a.a@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=ryabinin.a.a@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-39123d2eb7fso397392f8f.1 for ; Tue, 11 Mar 2025 05:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741695555; x=1742300355; 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=uMdqx5IAy5RwkV48z9EOvdZc6wlr4q4CS/HOkuwTfFI=; b=cLJwnHpBJewrtgY4aqWrZVoUSYXUrFoFudtBg4JqFcQ3h5llCkj8xd587vlsisMSns QBEVIh2ImsOWTEl9SV5DyEGogcMrBg5KHNC04C/QHSfViSkveqBrGSSy7755C4EUkcIZ 3HOsInHRTHUMPSvdxE37fm1IUdpKaTjewj/2eeoy8nhZOGNaMXVjofTprc3pR0DJ7slC S+2N3Fux9bEHlTNbXpwsuATQ2p8iT4NOVxYjiujC/6Nmhw2RhdtXzfP+DCXgVGjj27pX BS1EijM7ZLongz2JwO7urRSqBqjM/byF0yhqgROwz3LzFIVnOVs/70nW0jiVgYUAXfL3 8+aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741695555; x=1742300355; 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=uMdqx5IAy5RwkV48z9EOvdZc6wlr4q4CS/HOkuwTfFI=; b=HTb7WHAG5sH/4/Qgp49Rudz1VQdcXezoE8b5kAOVSHv5pQ5glXok6b6w9s01vTJe5o 5bXnU98NBhjxLw5MRYUsOs+CgfG8dmLqo1lAWGfMC6SNHQUYEJplP/hw3KXINTDtD7UX hM766AUrjD/3NKfQfDUn1L+S0w4s9IOhwfjX3aX1YmL8Mdmh3eB7y4cxcbC+u0M4WLYw TqB+KEyWK3BXynQHE6gxv7f3AITe6Dq1+WRlG7s5XMl0phLFi8G0ofbF2X8qyVrs51BT nISSNKFCISEwx7u3Afq+IAI5In/kbzGc9yxxemcosOpAV7StESRJenmBaHqhPJcLEXGz VHpw== X-Forwarded-Encrypted: i=1; AJvYcCXmID4LAtdkWXp3nJaoM4ONnno8el7tJ59oqHq9Xzy/y3n9TdXFVvgSZjkl6CT3j0XbXh29A7ZptA==@kvack.org X-Gm-Message-State: AOJu0YxFqrHlGHh0tBieV9N7hQcOBkswmxZfL7U/jHlyCJTKs38xEOxc oEFb/U034tgiQ+EthK8ny8oyVe7KZWNkjJMJn6CKmqQFhI3Noj7HqTdeQt1guoMXvyQ7pHsMxy0 YFs60BRM9vVgybrqsUXf69159Bxo= X-Gm-Gg: ASbGncuv66g2r04zoeCzrdCcvXvDwd+AQa3UzoooK7b9QZaA2U4y4URGA12tcwBUL77 5TY0qlccgnLdzhqkeyomZxNRvSeBogPbSYkBcoEDpt05iV9baRJy+0W5wYtYem9axL4J9M6s0jQ AUzZXqLE4u1Oqo+eLTKz+z44nMdt8DdHKbrcSsHVr05w+9QmGG0k+eqTAO X-Google-Smtp-Source: AGHT+IGz6yyYStQwXScQVA2NmPU6agIBdpm9T+QAnp5+AsC3//dJ8lHkSh1/zt7aSeT4AfjpaJGHgRPiVMRftVNRVSw= X-Received: by 2002:a5d:5f90:0:b0:38a:615c:8266 with SMTP id ffacd0b85a97d-3913bb2fac5mr4151795f8f.1.1741695555258; Tue, 11 Mar 2025 05:19:15 -0700 (PDT) MIME-Version: 1.0 References: <20250310120318.2124-1-arbn@yandex-team.com> In-Reply-To: From: Andrey Ryabinin Date: Tue, 11 Mar 2025 13:19:02 +0100 X-Gm-Features: AQ5f1Jp-4WIS7zgwSRZD9fIZPznfBSfecmUex3m3QdtGpEpLMxmRqOA6DAx82aU Message-ID: Subject: Re: [PATCH v2 0/7] KSTATE: a mechanism to migrate some part of the kernel state across kexec To: Cong Wang Cc: Andrey Ryabinin , linux-kernel@vger.kernel.org, Alexander Graf , James Gowans , Mike Rapoport , Andrew Morton , linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Eric Biederman , kexec@lists.infradead.org, Pratyush Yadav , Jason Gunthorpe , Pasha Tatashin , David Rientjes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 33614A000A X-Stat-Signature: bxkp1n3xnmp7t5stee9tdfbkt5ysc4fe X-Rspamd-Server: rspam10 X-HE-Tag: 1741695556-680241 X-HE-Meta: U2FsdGVkX1+XN5J7twkjh822DiwXUlyyEoYE3e9gvGF63988M1Gld16JIq6YKe7Y8eSD7jZmvQoUB5AyNGYoNT5yo+I/ryUTcBwUK0f9BVPYmqkqdkGNmwmtTzm/NX0LGYyhlzXPfrAb3p6k2cucZTTlno31DW6XQ1K1/Jbf4/CHwddnlkkylqNOg7tCYBDoOAjj2ZVMmnXLtsXTglJmdjBO8RhaeBOqveHZuj65TKnneFQ7uogs0QeCAKOtTbMcEpLAcmkaCK2mkVcWVtpmvuVIOYUHb8kWuFAMPUac/vMb+yGBMmeu9m+egJfT2DUtZ83xaPU3ZMceTlZ+knP45bJI0E6lXT5kGGdkokCY43LcdGuMGyrrHYn6KKtaX7sw0IU1gWT3aSZ6rJtfhU44Gul0/DWQsgb8iF3dz4BmKgcl+iF1DtOmdDDh7bcJ80KTdORZEWUMSXd2YWr07pTKt7Yek0M1peiatkFaFk9KSu7A9fk2gNZeleNxMJE8KTF/2CspMb7AM6UInjL3Y5wijTWbUyNwj9ET63YWAYYuvpk/AYA7JSpWzrvHgIQokT9S3fX/i1NPfDnUj5vJTii3lFJh0OOH0kokirk2dJEhFcCiAEoVWwtbfbjJVqwMeUXhys2mCkFiGIxQqzqa3vvICnBqH7oPfFQElvM5iBPmHCpxy7zVd1QrS/g3UMP2ApUh4zAFbzyInCaVVQtmqaS/7BIgRr+o98QEgnRm6Q5dnUkuUm0TI0ZqWt3PlP80opmDSlHv/+VWnXgp56HLddR17Kjaty/kBtPzpreUJok67alc2QJfk+fBui+2vdTW35dl2ilkiERLa7BcHdwQQ65chTkE6WkpjlTFV3my17nxTlZXu1Jae5y2MDZrY7B1WFW3MjeaJxN+9u9U/NzbFsZBERomHIKU50fQDu5iOuYLCVQTe+MKhHfAHTWh9rITEABfQzd/gVBNBu+Rmi9OqUc dfVUgvmg zTndcRbYY/rVgv6hWqgQzeY8kKd4yVCa5et00yjQT+X/epa7TMagySM5F2X5veD+EYEF8dJe7dFsUuWwbpwQN8qW0dsf/iJ+yRLQl99xty4GlWd8dKWyG1dDrCZ3rT4i0o/ixzYfwPRTjNpnRQ9tSlbzvoTWOdKLkVwnxOP8KHTPm1QD6NCLubN9MVRywO7Cbq+wnN61QVKayx7I+/i3y80LAULGuLoXAj2xNeH8eek4WdRIKC5hJecs1Loj/uCew68oQ0hVMpY/h+lVs45CsXjJXAx0X+PD54hzxw3AQP6Oxpgj5aH1ZyZBuCpWYyr3AauPg+VPbcjah7U+x2S4o8qI8K9Z+4BaXemqEYzE2XJr738XlaABs6yfWyy3+OsY08VEc/aLIIXSbwgT0jRKBQhkBrgrFXbxnZNmX8G8ZTCVNf1ZVYRaOeqK9yqE+uCDWqKL17syaYcPpMDUWYz2Kaz/eDrM52VaDHf3qO0jjljdpMS5PXYcKHaLDMDKkKnFaAlLQMjCPjzlaXIHpnhgfvFJj/DgiudX6rAIiwVozXLOvx+8= 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, Mar 11, 2025 at 3:28=E2=80=AFAM Cong Wang wrote: > > Hi Andrey, > > On Mon, Mar 10, 2025 at 5:04=E2=80=AFAM Andrey Ryabinin wrote: > > Each driver/subsystem has to solve this problem in their own way. > > Also if we use fdt properties for individual fields, that might be = wastefull > > in terms of used memory, as these properties use strings as keys. > > > > While with KSTATE solves the same problem in more elegant way, with = this: > > struct kstate_description a_state =3D { > > .name =3D "a_struct", > > .version_id =3D 1, > > .id =3D KSTATE_TEST_ID, > > .state_list =3D LIST_HEAD_INIT(test_state.state_list), > > .fields =3D (const struct kstate_field[]) { > > KSTATE_BASE_TYPE(i, struct a, int), > > KSTATE_BASE_TYPE(s, struct a, char [10]), > > KSTATE_POINTER(p_ulong, struct a), > > KSTATE_PAGE(page, struct a), > > KSTATE_END_OF_LIST() > > }, > > }; > > Hmm, this still requires manual efforts to implement this, so potentially > a lot of work given how many drivers we have in-tree. > We are not going to have every possible driver to be able to persist its st= ate. I think the main target is VFIO driver which also implies PCI/IOMMU. Besides, we'll need to persist only some fields of the struct, not the entire thing. There is no way to automate such decisions, so there will be some manual effort anyway. > And those KSTATE_* stuffs look a lot similar to BTF: > https://docs.kernel.org/bpf/btf.html > > So, any possibility to reuse BTF here? Perhaps, but I don't see it right away. I'll think about it. > Note, BTF is automatically generated by pahole, no manual effort is requi= red. Nothing will save us from manual efforts of what parts of data we want to s= ave, so there has to be some way to mark that data. Also same C types may represent different kind of data, e.g. we may have an address to some persistent data (in linear mapping) stored as an 'unsigned long address'. Because of KASLR we can't copy 'address' by value, we'll need to save it as an offset from PAGE_OFFSET and add PAGE_OFFSET of the new kernel on restore.