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 74243C5AD49 for ; Sun, 8 Jun 2025 15:08:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B450A6B0088; Sun, 8 Jun 2025 11:08:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACE956B0089; Sun, 8 Jun 2025 11:08:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BD656B008A; Sun, 8 Jun 2025 11:08:48 -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 73D096B0088 for ; Sun, 8 Jun 2025 11:08:48 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EDDAC1A1885 for ; Sun, 8 Jun 2025 15:08:47 +0000 (UTC) X-FDA: 83532565494.07.5378F9A Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf25.hostedemail.com (Postfix) with ESMTP id 151FEA000C for ; Sun, 8 Jun 2025 15:08:45 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=GeSTn5zw; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749395326; 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=lzuRPFYIZRvhRVOmWKy01BEcZ/VAU38+zCshzHdk5c8=; b=YtOb1Fr0wywCHbU/zMF57zTAAYy574IBEQw7mqGl5QWurqtAf9C7IRpF/xM22rGQcjO9JW 3TY5WzfgerDXFtnlk8ArHRjWKZRNCxtnM+X+thsNWlYgVzhobFIRUzBrV8J63a4iAhmPQx CZmoH5BlC0+oBhLb5c0O85jfnKOHMpk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=GeSTn5zw; spf=pass (imf25.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749395326; a=rsa-sha256; cv=none; b=x5vfYki/2nWr7c19g5/CcBXFjXVum1Z0SsGkHw98K7Opj6pGGayFhaNLYPZGwCH5pRce2e RpIV4/6RWZh7WaocvYoymPBlYQ8qWS11F2VxfNK0fdPngRUPPpRDuYdHxQrva51u8AePwd jnBtTsPMT1NmdScEQR/w29BingRrbkk= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4a44b9b2af8so21343991cf.3 for ; Sun, 08 Jun 2025 08:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1749395325; x=1750000125; 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=lzuRPFYIZRvhRVOmWKy01BEcZ/VAU38+zCshzHdk5c8=; b=GeSTn5zwm/gvqtVhHjfA/bAHpHTODo04c6l0BiBpAUH4bBdsnrMgobXufcPd7vcNnn RU8/wzTVxcR12rRZyTlTa3uJUa8d3LRx9V7oHvjsnQ26G84NbpxUM1cDuMsmmXoGniBj 31OoL8nP8fGP3f+PhPw0HD78iEFF2HbrfCzDq3qSk1mwJkqfeICE2wrAujLfLrE3Efp1 oWfernlLf0AuQ77jSJ3CQ2MgqsC7UaMYxw0R6+v1pzhstSky0sLm0U7c+aKJ08U0GmIy PpLVoJsyKs9cs13dpqXUlYQHEXrO1rvV8eRiYV3fFOCa/YM9QcskiVqaQ4KhIavseIDg TqKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749395325; x=1750000125; 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=lzuRPFYIZRvhRVOmWKy01BEcZ/VAU38+zCshzHdk5c8=; b=ZSZxeeyCy1D/eRvBH0O0ql5XI821zsMNqDCTqIX4IbxXxULuGhDd/9eFZ+/fLpc/ra lOBHdOo/KiP7VHO32zsqhRr1EEFifb37t7zJDbvLbYjagTtWkDt1WWaRqS7FmtoLlvi/ 2DzsyVM00Yhxr/X8HWguFUttohzx25ztCczw6k2LMlUhwV8qN+UuTVlwQmsZOiOYtS4l MYCmw4PxopDarfly0nk5bki5U5QzTbdFw14ksxuU0MI9S8razHetbfx/fOSeufiOSEu4 8WlHd8w24Trr5jtpbILuF/BvIK4QVo6+3dmHcLwdsRQAnPbP6RDPEFAT13CcAGC6oh7h BfYA== X-Forwarded-Encrypted: i=1; AJvYcCVJFoUckmN77Gofut4qiSp8Mpyg0V/pSIRd9oecErhsa4tElR5XzTcjQ0Oao5vwY30WZRsymixVSA==@kvack.org X-Gm-Message-State: AOJu0Yxa7ADv4TLohs8lMozXDNaElzyfDDzx/a9XWVbrFde+AIQJpTMx bS5Q7k1imh0dayxmXwxOUrFN23BU3Mc/Q6NGr0rAWkl7ZINKKYUl3OjgLnZ0GKItm4NYZfJ9UGD RtOCVo2MDoBGVYM5wLHdkG4WFaqzKWCi1/DWB8HCJGw== X-Gm-Gg: ASbGncsPXGxSM+6A4dA6LPl9fc8vGH6kybN8rnc5gK/r59y0zWs5XdF5xlY+W6MiuDO GFXZtzs7sD7aTLjxKHpmwNPB955wEFxfbwc6CQ3DGz3VQih73udjjTcST6POlBEJD7utnDEOvCO a4AIlyh6eAkG5/m4NA2YFIXKibkpVl1A== X-Google-Smtp-Source: AGHT+IE6Wavjh9lcZ08UG2JWQl0zBb+su/qycW7Wdsq/33CsGFoBpF8qSQTR9wAEzhKeUToBRdcuafqk0yX/KDtvId8= X-Received: by 2002:a05:622a:411b:b0:4a6:f99c:395f with SMTP id d75a77b69052e-4a6f99c3abdmr46534851cf.44.1749395325030; Sun, 08 Jun 2025 08:08:45 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-11-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Sun, 8 Jun 2025 11:08:07 -0400 X-Gm-Features: AX0GCFv10U-Kg40y4yXNpa11mJu1sY2K43SsH2vGJvqSKTOZOwQxZ_Kd2f14iWc Message-ID: Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface 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-Queue-Id: 151FEA000C X-Stat-Signature: 45wnbmrr89xrcqtxecjc3km77w35mcia X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1749395325-788661 X-HE-Meta: U2FsdGVkX1+AWO60SiGnS8/mj6Q6G7yx56KMIIUdz60mzpQmuDRXFE5FsHZmbbQ/vew+U2uU3yRKefBlUDNAVokoor+jMO4TqsIJGsnZplzYDH3nR+yX2OfBwASTKWK/YU/OmnvCX8vtEkjiwoXkZVkBU+uTZtkpq05Zx/JbovH51z7mZ3A31dDYLVxHOLZYmLOKSvCOatw9UqedmgaW3v/i5MjM5Ufztk7w6DVHimRzA97Iuz+ytsH5O5yP92iDcWEf55wQ8usgxeWWPYs5v+d3y9uMoWxOZUJFaJUBB5mh2c3HQazxMjky+0RhJC2CnbCLL04TFxkzJq1emBtXaI3wvYxhWUXzyW3yH7+5GX5lFcf569I3FoNvXHgcRS4Nm6903u3xSg98pPK2BYdAL89fd+atYD3YCNYEj1YRZe9pH/wIN0eBo2KL+6DZNAZKTMFzIE6IB8KGxb2fvoX4jO5aWxjqsp1b20rSUkCHDEFaI3bxWjzeRyAD2ltalxe0Ryh0r16BXSdf/z3SQPuTq6M0H7XOfSpnsjXFSilrRMmlUM5096Srmgid2IafjJiwF3Ab4QX2VkPlS40457srUOUJh5tcOKK0DHX5R7O7F5U9+ced+nmm6f1x6/GItEEWF2Jw3/OO7cXYdCwMrAfC+N7h/y5gAghlCgWE6y86WMDylIdgyphUAjxuxAceox4fx5p+tnx2Q0F/wHSi5TnaiGPef/4i+SYovRktvO7KodpohlhOGecNcOvHJashmBGSsbfhqS+yl3xHJDZUa3Ve05JVGqElNCOEuaHwL6b8dq9YaeDwmkpTE3ztQT5yMVRcwdHX/yn5lLqUwzpUZv+9wvEro/sxTMV75CcEW8gPbWseQJluLrcBzuI4HhnvcHm7OJV+BeUNdzm5H9YaFxoD0ALgDsfJ0nYIA3BFVrb2eHvitbUbIHSs84MhY5i4ME2cyZF5GXddz/1XZi7TU6g t9wBHnGT e7S6EHgXTeHzhzpuXUeAKU+VlnSQfA52kyfUrYiWMxAb693M6cBN1Zh59qDFDYqpw92mf81d0W8wbMHiTrv0faW3tMaI7zHm8rSUER3VxeGPHLCwjMRfUalx232vRNhSlWUu9+TFuBbPvIFA2MG0+Bo0nmT0jCS6qLRgJxlImN17XBxVGFj5P/scAergjG1CdK5pNYeywmEPa700sO81Sdghb3NfdLSC8mRXCEF6XzitcEOBvTAQCeHmtNLPTNanU0+PeKXmgg2kzP+T7drpvMAfv9rCk34Oy/37G+htt2BVkoEsXHp8fuKA6FjckgF5B8G7fd2OOGXHGtICqh+YPf9SOQ/WYy6dObfU6xOhbQJzANzXehThIpHEfHj1LtwMXRtUU0RH9RyekizD+UBY1z00Yg+y/Ra+RevmEOo6sJmNjiM5RIMpKe2bKIlZb068yxygNlR949Z+EXds= 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 4:43=E2=80=AFAM Mike Rapoport wro= te: > > 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 upd= ate > > - * orchestrator. > > - * @LIVEUPDATE_STATE_NORMAL: Default state, no live update in = progress. > > - * @LIVEUPDATE_STATE_PREPARED: Live update is prepared for reboo= t; the > > - * LIVEUPDATE_PREPARE callbacks have= completed > > - * successfully. > > - * Devices might operate in a limite= d state > > - * for example the participating dev= ices might > > - * not be allowed to unbind, and als= o the > > - * setting up of new DMA mappings mi= ght be > > - * disabled in this state. > > - * @LIVEUPDATE_STATE_FROZEN: The final reboot event > > - * (%LIVEUPDATE_FREEZE) has been sen= t, and the > > - * system is performing its final st= ate saving > > - * within the "blackout window". Use= r > > - * workloads must be suspended. The = actual > > - * reboot (kexec) into the next kern= el 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 operat= ion. > > - */ > > -enum liveupdate_state { > > - LIVEUPDATE_STATE_NORMAL =3D 0, > > - LIVEUPDATE_STATE_PREPARED =3D 1, > > - LIVEUPDATE_STATE_FROZEN =3D 2, > > - LIVEUPDATE_STATE_UPDATED =3D 3, > > -}; > > - > > Nit: this seems an unnecessary churn, these definitions can go to > include/uapi from the start. True, but we do not have a user api at that moment yet :-) > > > diff --git a/include/uapi/linux/liveupdate.h b/include/uapi/linux/liveu= pdate.h > > +/** > > + * struct liveupdate_fd - Holds parameters for preserving and restorin= g file > > + * descriptors across live update. > > + * @fd: Input for %LIVEUPDATE_IOCTL_FD_PRESERVE: The user-space fil= e > > + * descriptor to be preserved. > > + * Output for %LIVEUPDATE_IOCTL_FD_RESTORE: The new file descr= iptor > > + * 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 prese= rved > > + * resource state. > > + * Input for %LIVEUPDATE_IOCTL_FD_RESTORE: The token previousl= y > > + * returned by the preserve ioctl for the resource to be resto= red. > > + * > > + * This structure is used as the argument for the %LIVEUPDATE_IOCTL_FD= _PRESERVE > > + * and %LIVEUPDATE_IOCTL_FD_RESTORE ioctls. These ioctls allow specifi= c 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, t= he > > + * kernel populates the @token field. > > + * > > + * After the live update transition, user space passes the struct popu= lated 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 fiel= d 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. Good suggestion, added. > > > + > > +/* The ioctl type, documented in ioctl-number.rst */ > > +#define LIVEUPDATE_IOCTL_TYPE 0xBA > > ... > > > +/** > > + * LIVEUPDATE_IOCTL_EVENT_PREPARE - Initiate preparation phase and tri= gger state > > + * saving. > > This (and others below) is more a command than an event IMHO. Maybe just > LIVEUPDATE_IOCTL_PREPARE? Renamed. > > > + * Argument: None. > > + * > > + * Initiates the live update preparation phase. This action correspond= s to > > + * the internal %LIVEUPDATE_PREPARE kernel event and can also be trigg= ered > > This action is a reason for LIVEUPDATE_PREPARE event, isn't it? > The same applies to other IOCTL_EVENTS It is. > > > + * by writing '1' to ``/sys/kernel/liveupdate/prepare``. This typicall= y Oops, this is a leftover from LUO RFCv1, fixed. > > + * triggers the main state saving process for items marked via the PRE= SERVE > > + * 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. Fixed Thanks, Pasha