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 85E59C3ABA3 for ; Mon, 28 Apr 2025 23:02:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 266566B000D; Mon, 28 Apr 2025 19:02:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 212F36B000E; Mon, 28 Apr 2025 19:02:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DAE56B0011; Mon, 28 Apr 2025 19:02:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DFE1A6B000D for ; Mon, 28 Apr 2025 19:01:59 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7C5178171D for ; Mon, 28 Apr 2025 23:02:00 +0000 (UTC) X-FDA: 83384977200.11.77F747E Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf09.hostedemail.com (Postfix) with ESMTP id 572DF14000F for ; Mon, 28 Apr 2025 23:01:58 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qJHzpRfZ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of chrisl@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745881318; a=rsa-sha256; cv=none; b=lrY3wh2xztP4mMGCv9cVQZYM1sM5d9/2gSaTgxFOnDUjEELDkjnNVhPHUGFr9kXovE5LmM qD5SBp2LhzOjim2h3f39FTaxVBWS2c0ymVdR8qUOXqJbm0QUfe9wTxue7H1Xx0g6vcY508 UbGhWBkffkyUB77iaYpc0F/B+wHDm4c= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qJHzpRfZ; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf09.hostedemail.com: domain of chrisl@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745881318; 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=HwBT/ovUEv8UzpWAZc2njxR0ZKeSaS/THTkBms/bELM=; b=eQl0GJUDqZkJHcwxjUvK2B4lGm1rFPl/+jN8mCTntwuOAfOFr5m02eUpkXLc/Uk7oBNfZS t5uOhX1m5/ovY6fa+Yjx7QbbznacieSUi952jlPdAyz6jhaBO1kKEpeXKMN/nzeIxO4k8m hMSQWw2viA1GXDgByhYbzRMpPfT1J34= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 44E5C4ABC3 for ; Mon, 28 Apr 2025 23:01:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E6DEC4CEF9 for ; Mon, 28 Apr 2025 23:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745881317; bh=HwBT/ovUEv8UzpWAZc2njxR0ZKeSaS/THTkBms/bELM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qJHzpRfZ+tCuI02iRkM858HwNpAXUci3xSnPoO2kSqMlpLH3MrTzZTRU91ZzwV6fg YJeHtF/oidckWUJvg6SPJX98M05AoKqEHWy7cvVPR6UJf7CPtg/SpfqJGHR3R2gPYt /0nm1odKhCoCQI7K+n/d+d7SAsdHHoMETwGyruiAqjufqzGINX7Rt2XNRq0lsnBKJG sx+4Z+QwV19xl39JylyUArWFVbkWmLKYRCXjGZkUuckn9JVzJL2oA7Th/wFb3eDVlH WUlVS25qp02PTXy38HrD+mdv6oP/FT9vHvoqKQiPqF6KveNAu4SjOTD0Nt8OWVRkJ+ 1Gn79zG0zHPqw== Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-43cfe808908so4325e9.0 for ; Mon, 28 Apr 2025 16:01:57 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUW0B3b9fs91g9U64r/K3uiJSnAmQBE0PhvnpXa7JE41HmTn6p8VkfnM13Df6P7moapyx5qoqNgog==@kvack.org X-Gm-Message-State: AOJu0YwCHYhMxSte5Ew0TYptrcR5/S2qrsXthfSccAyBuYczxNikvGvr n7vOMj332bt6AaEqwZfOLuuCHqIb+V2KVQ/HT3rRhbzaf/fne3cqkYUBSzhy255UDDuBUO64j3w i6jEUWrMfUnjoSOQ1nHTAD7OVSRWVHgril/Wt X-Google-Smtp-Source: AGHT+IFltF0sFMEKKxvR5oEXrKzNbNJnpjWpEV2T1C13cir292/kbjIpYGja2HYoKWTK4fMkgc7VXYkgS3IGbLrZCG4= X-Received: by 2002:a05:600c:35ca:b0:439:961d:fc7d with SMTP id 5b1f17b1804b1-441acb99999mr528205e9.6.1745881315845; Mon, 28 Apr 2025 16:01:55 -0700 (PDT) MIME-Version: 1.0 References: <20250310120318.2124-1-arbn@yandex-team.com> In-Reply-To: From: Chris Li Date: Mon, 28 Apr 2025 16:01:44 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: ATxdqUFGsN2yKGjnSWE8Z8P2YNgx5olP5cHe8TNU73XJyrvNYVVrVxIXXPjB6GI Message-ID: Subject: Re: [PATCH v2 0/7] KSTATE: a mechanism to migrate some part of the kernel state across kexec To: Andrey Ryabinin Cc: Cong Wang , 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-Rspamd-Queue-Id: 572DF14000F X-Stat-Signature: 79hh4aytymofcs4p9gfjzrbxtqrt376x X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1745881318-42750 X-HE-Meta: U2FsdGVkX1+HgohlD3/B20cBF7EuvLRK5mnAm7xy2Rq7+yWUyfjrXl/HK7TfMZbjVTMFhA/AEcP147JcCQmdl1nXIu6tdbiw9d8G8QI87NlvA6ib7iKK7EZTInluJBJoSa2l70fr8kc38mDZiWciwg5TT4YcHSOeLROKZM5oUeZYwmP5VE+KJtwxzuo6bb2XxLwwti7zdz/Jw44+vkcy/6p45aMig+qyTVgTCoYVLe7GTo51WPUdy6nuHzn6KJ0T2JKvuoIu+j+sbKyajb9s2VoKmWkOTm3ugFn6waoZhPciXYUXpsS/w8nqUiXUSsZsXqagzCScp8n1BUrYsGqQX+SDQRX3apI6SwZVQZ2C/D2cAP8YYMZW1wVvMbvGye+fAgVIp0zBs3/Q165571RJogsMx4awEcPTeo2qCI1zi9Cj+yQr2ojIa9x2Bp0KFR52X6cd1nJ/Rqj98/Y/UnjuWY4pyRMHfEgNuIVCkeWG+7FrZIKsalFNA9ZZfO76SVlXLsbt5R3u8T3LrTRjqliVpc9uJTBip5k2eUxV1JmKjMrv/tUsQ90ncOb3HOEIc7N4s7ATZHhgBsdEObdT2VqY4WeBHZ29a4OHiP8Y/3Q5UmCDu+mbqS3XKimEus0vKgE+Fges7Nb+eBgrkS9+CXH011Ktwjmwwe6vhjoIW4T5r0glzt+pBZ06JlAFQ/nXN7YGZQ19EjBy7ekpAGTJz8faemLW+MqH/OyaXpv1aA0NmEPyocpKODZDQgGT10BO1nrgt5EgMSTQxMfPoNM2u6kHJD4+iQwb13laAnhcls/KAQxcDay9Z0AoCS60vZ23tGjPrcWabwu3raMhFG447+SjomIP1LCXRxOn8/0pyndKwGVnhlRuKJpvByh0Wl/iz8WPUtFShyYVeugdXQQhSJpB8duKwGYrMLsXhHlqtbaiAbodlrQrDtBS9WJNfCYdYB+inakXG0LoI4lgsdCqPXq 6/fGIP8A hfcOqVDJXtNPIF7T/qPJjIbWH1YwsjUnBL7w9mQOAtK557cLN0HZWNEEeaJ8e0ShpJHsJlSppaGjdFeAIfyJuYqMMKMVXU00SgTUcEz+gCxXmlpHRF5udgSK2GKb1fQH1YNUj1beeoAH9v9GXeQyKAh2phVNmGR0SYYE3jWJ+E65Z+8Hw0D4pCtYG99q83PtWxolDTcVxnd1gKi23pVwQ0qUxpX3ENEQJwSzPp3PbpwsEkPJi0LWCNNrHwNpSxgYjGyoeEOgS6prZjrwU47wTr0/dN35M/OOU7+sPkIjM/dMWzYiOFgX3601NP8oElUVqyaRKO6e+qfd9Als+fALDNIkmJIE0x+RioR5Z7LxetBI8Nz1ZYsU5dNj4BR7t92+6TESNEFpc5TttWnv2SILvuYqSzBCowiMhu8xCU5N0GkWihxw= 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 5:19=E2=80=AFAM Andrey Ryabinin wrote: > > Hmm, this still requires manual efforts to implement this, so potential= ly > > 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 = state. > 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. There is some possibility to use tools to lighten the repeat portion of the load. For example, the use sparse checker to example the struct field. > > > Note, BTF is automatically generated by pahole, no manual effort is req= uired. > > Nothing will save us from manual efforts of what parts of data we want to= save, > 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. Agree, there will be cases requiring manual intervention. It is unlikely to fully automate this process. Chris Chris