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 E85B1C54FB3 for ; Mon, 26 May 2025 08:43:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EBA16B0089; Mon, 26 May 2025 04:43:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C34D6B008A; Mon, 26 May 2025 04:43:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 500AE6B008C; Mon, 26 May 2025 04:43:04 -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 2EC286B0089 for ; Mon, 26 May 2025 04:43:04 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CD3F5C05F5 for ; Mon, 26 May 2025 08:43:03 +0000 (UTC) X-FDA: 83484419046.25.63F25D5 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf10.hostedemail.com (Postfix) with ESMTP id ED3B2C0009 for ; Mon, 26 May 2025 08:43:01 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lnbFa4cH; spf=pass (imf10.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748248982; 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=HjtgnbsXhbSxhPMLFnBFzKK/ZJpIUjpwPv7KRHTllRo=; b=op3OWMTSxgQfDzFKVMNcjAfRaQyYf6BFsoNAVhiN437Y7NgLawTZymTGsodEzKI0gJJ894 RHJeJ+4Jr0FEuzNVOvuK6baka1SwCBz/EJy+SK4RwgfPIhxl9oEUW6XcBGY7GJmGm2PCTm MAje2JOnSZJ6+hIsuM6Y4tKqiuFteJc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lnbFa4cH; spf=pass (imf10.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748248982; a=rsa-sha256; cv=none; b=Or9TqFjlVcZREzfYtT37mrSdXlistwUK6LQZxBfOEg5PrwoFQy6rrOIMJxPoGjD5WDd08X dNpVt8mUIuFIcDZ8C+NH+KxDvAoG0V/zX806InIabV3MTHksQjGDSx5/IJ6t9Yhpac5/4M hkYx45z46D3NnWOa3SrkSMZbLfs9WMM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id A652C4A193; Mon, 26 May 2025 08:43:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B754C4CEE7; Mon, 26 May 2025 08:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748248980; bh=FcJdfFFxShk3YZXuaYCNmm4+hYbTjiztce8ew17pr90=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lnbFa4cHSvgK+Qehdz8hCiwz9B6ysGp++OYKv4ATNTws0oMYDe9I5jDgXFUhM9XVQ o8n5XlWze2x4AcdsZIqvrWTZ3Lr8hAPD8f8OGpWQl10XkYeWPwoYIeKBgf1vAPu3Gp SUG42rl3nLDP6CKx2cKGI1RndqSOTCtLfN+V2e8K0qLo3WeQwbMpaXjGRHpMsQ0zLq u2ykFu1MdWX/Zb2PxKGKeThre48Fi+312JSB7zK0d3Kq5PxkhPnz2eg1wIt/XzDN4e /ATyfW7f359XDMhWa8HOY6niQN+kszbFjuPIopg7Sf7SMtYoPE6lp0rhlFJGiRgEl0 JhT0KRH5DKQcQ== Date: Mon, 26 May 2025 11:42:38 +0300 From: Mike Rapoport To: Pasha Tatashin 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 Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface Message-ID: References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-11-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250515182322.117840-11-pasha.tatashin@soleen.com> X-Rspam-User: X-Stat-Signature: 8rhmyj8nq7f86pf46t7h7pchsoxr4hyu X-Rspamd-Queue-Id: ED3B2C0009 X-Rspamd-Server: rspam11 X-HE-Tag: 1748248981-617449 X-HE-Meta: U2FsdGVkX1/O8EgKN6mMfsUYq/os3BOsC79jc3BA7j81/LSP280NPJL+Uey1e5WjrBBCtx9OY2tz7eqjmfMoC7VW5DxUaIDW/Ff8Yw0ihSQgdGl35Q1HemQmDqcA2fPQotQb4xC+/OWa+KA2IkUusPw6AtJsLqwdK/ZNjdQ8xP2iylEtkml2bYhw6Gmixelykd5iPPSfrdbUFdfMDgWoKM5rc357BHtlWWgEf6QcnhYUApER+5hE+hV9a8zG7P0ZwElXt4kCsd3mND9GPxbXaoqdj3e4VUmntoFzPs1DX5Rm9NayNJu58C6S2ozpVp6uj5h5XD6w+5QKI2jTLli9cIxi+NnodbJ2ziOlqlbh1R22WJktDMFZMhEvRwpjEKrcAV6CjKwd4dkGOllNZpRziv4QFgvXo7EXgprVgK01oG+ERPdqDNQfEjeoo3XpjseOeTnwCheaO6hdQPiyHhYG8c1fnVp5pYtaoOsE11Iv49eijkpWIGcIvcX9JMDUEKRDLFldq/sRgJx+HZ9xypybVk4IyunKNrTfnMnMdj1P1OvuvEUq8iyiWKEfQq4Su7i0HSIGec0B8vEvHOX6CqWCmg+aBmeM7sl3edQFl6xCIRhSn7ceyeVdMeEQAH1MsJfo/EEQhEzTVg2RmWphYVx9+0ptpqJIK/aHlXx6lOrR5TMDRoms7LtLbOdHeE8t82izzbAQV36nIceGAlbOWi8AOivbqq1N2HVDGeJlCaJoYUKDDRwV/HM3MSU0I2IMlov31BxnCYsC0F98wxBzrMEwPvMPPmMONfvDiFteYKhFCMHn4kGU2jZ+dnSlxSt3ZgtoH8uiLAVPs0lb2T80CCTTqCgYY2twgeDiiwoHEUiC8SKIHi6CSTYa6eePUVRc2I7aaa7tkjAU16MXBsP6djMfmomb3QUGFapph87sdNBarwtfrLYkSTW/WySpucmFBdECAlhezNXUO+ha4Riljf4 StnoLd3u +jaKMTqHD+gJNHrxCl3tsWdppZ1yHO9o/ySwI+9MBD6E4zxA0ovzyCjE96BjUweTfeB925NH1Xw4Q2GoTFDHqWtD1T9JJMuBNeSg+g7BTKDMhmVLOFhTUZG1Q5Kfte+G2Zm7Y4aM0ExTrqZ320mt9eS2QPusxw3g7rZsqBPm3vrMXbzGjczapd+tTYhCEAymGxVRxNgLK5sAmQM31xpdat0V09vB8rdwhORMH15v+pqeGMKAKo/+D76jxQHF1gaM/fYwFm2KTjWDHIhBb2JifAe7mpljN5X/swSkyfNiQil44UzOA8DfI1Tn4ztXvbvh9hfsg46ll6kRZ1MOtdJXlEaCRROGwgBY4wky82s/NlE/luxNmQSrwN1saqidMVSW1NWNOFhno3rYG1a81wVjrBg29FiRHfVROiWA0S0I0FkDHLlrj876d1ajN7A== 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 Thu, May 15, 2025 at 06:23:14PM +0000, Pasha Tatashin wrote: > Introduce the user-space interface for the Live Update Orchestrator > via ioctl commands, enabling external control over the live update > process and management of preserved resources. > > Create a misc character device at /dev/liveupdate. Access > to this device requires the CAP_SYS_ADMIN capability. > > A new UAPI header, , defines the necessary > structures. The magic number is registered in > Documentation/userspace-api/ioctl/ioctl-number.rst. > > Signed-off-by: Pasha Tatashin ... > -/** > - * enum liveupdate_state - Defines the possible states of the live update > - * orchestrator. > - * @LIVEUPDATE_STATE_NORMAL: Default state, no live update in progress. > - * @LIVEUPDATE_STATE_PREPARED: Live update is prepared for reboot; the > - * LIVEUPDATE_PREPARE callbacks have completed > - * successfully. > - * Devices might operate in a limited state > - * for example the participating devices might > - * not be allowed to unbind, and also the > - * setting up of new DMA mappings might be > - * disabled in this state. > - * @LIVEUPDATE_STATE_FROZEN: The final reboot event > - * (%LIVEUPDATE_FREEZE) has been sent, and the > - * system is performing its final state saving > - * within the "blackout window". User > - * workloads must be suspended. The actual > - * reboot (kexec) into the next kernel is > - * imminent. > - * @LIVEUPDATE_STATE_UPDATED: The system has rebooted into the next > - * kernel via live update the system is now > - * running the next kernel, awaiting the > - * finish event. > - * > - * These states track the progress and outcome of a live update operation. > - */ > -enum liveupdate_state { > - LIVEUPDATE_STATE_NORMAL = 0, > - LIVEUPDATE_STATE_PREPARED = 1, > - LIVEUPDATE_STATE_FROZEN = 2, > - LIVEUPDATE_STATE_UPDATED = 3, > -}; > - Nit: this seems an unnecessary churn, these definitions can go to include/uapi from the start. > diff --git a/include/uapi/linux/liveupdate.h b/include/uapi/linux/liveupdate.h > +/** > + * struct liveupdate_fd - Holds parameters for preserving and restoring file > + * descriptors across live update. > + * @fd: Input for %LIVEUPDATE_IOCTL_FD_PRESERVE: The user-space file > + * descriptor to be preserved. > + * Output for %LIVEUPDATE_IOCTL_FD_RESTORE: The new file descriptor > + * representing the fully restored kernel resource. > + * @flags: Unused, reserved for future expansion, must be set to 0. > + * @token: Output for %LIVEUPDATE_IOCTL_FD_PRESERVE: An opaque, unique token > + * generated by the kernel representing the successfully preserved > + * resource state. > + * Input for %LIVEUPDATE_IOCTL_FD_RESTORE: The token previously > + * returned by the preserve ioctl for the resource to be restored. > + * > + * This structure is used as the argument for the %LIVEUPDATE_IOCTL_FD_PRESERVE > + * and %LIVEUPDATE_IOCTL_FD_RESTORE ioctls. These ioctls allow specific types > + * of file descriptors (for example memfd, kvm, iommufd, and VFIO) to have their > + * underlying kernel state preserved across a live update cycle. > + * > + * To preserve an FD, user space passes this struct to > + * %LIVEUPDATE_IOCTL_FD_PRESERVE with the @fd field set. On success, the > + * kernel populates the @token field. > + * > + * After the live update transition, user space passes the struct populated with > + * the *same* @token to %LIVEUPDATE_IOCTL_FD_RESTORE. The kernel uses the @token > + * to find the preserved state and, on success, populates the @fd field with a > + * new file descriptor referring to the fully restored resource. > + */ > +struct liveupdate_fd { > + int fd; > + __u32 flags; > + __u64 token; > +}; Consider using __aligned_u64 here for size-based versioning. > + > +/* The ioctl type, documented in ioctl-number.rst */ > +#define LIVEUPDATE_IOCTL_TYPE 0xBA ... > +/** > + * LIVEUPDATE_IOCTL_EVENT_PREPARE - Initiate preparation phase and trigger state > + * saving. This (and others below) is more a command than an event IMHO. Maybe just LIVEUPDATE_IOCTL_PREPARE? > + * Argument: None. > + * > + * Initiates the live update preparation phase. This action corresponds to > + * the internal %LIVEUPDATE_PREPARE kernel event and can also be triggered This action is a reason for LIVEUPDATE_PREPARE event, isn't it? The same applies to other IOCTL_EVENTS > + * by writing '1' to ``/sys/kernel/liveupdate/prepare``. This typically > + * triggers the main state saving process for items marked via the PRESERVE > + * ioctls. This occurs *before* the main "blackout window", while user > + * applications (e.g., VMs) may still be running. Kernel subsystems > + * receiving the %LIVEUPDATE_PREPARE event should serialize necessary state. > + * This command does not transfer data. I'm not sure I follow what this sentence means. -- Sincerely yours, Mike.