From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f46.google.com (mail-dl1-f46.google.com [74.125.82.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C173732AAD6 for ; Tue, 30 Jun 2026 22:55:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.82.46 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782860141; cv=pass; b=iAlf1zL2FVCE/QynQyvneL18OepGOCofCJMQ8qULLuO8ZkgYQsP8YZWRmZH6e3KAcPMiXcFFn6TcRfdsTT7lBzHFzcYsSGgZIzAOaT6n/QIfP9Fjb6+lDVa+d3vRfmUi/C+gD+cSTPRquuYPpDNr1QhlNPP9dol/n7iA6DqCXNk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782860141; c=relaxed/simple; bh=U6P6GVenUM7M1V04XROjUEwO48BnDDCBFpmQQ3vqOPU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N5K0DolwbhnoOzCUqjVkwXzoEoYJhRjg2kKlhVUPlc6xSJl2t0sg+ryZOq4PhsTlFmBcmkelmQm3YmsgPCNgvFyQ8xlDJUb1vr7rhJZABfy1mMtcjtY1ZH5ZqYg9B0k70t3y1PWM8/mTdS6VhE4+O/eebIQKr3YG2+KUo+GpARo= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=jwwkbQXU; arc=pass smtp.client-ip=74.125.82.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jwwkbQXU" Received: by mail-dl1-f46.google.com with SMTP id a92af1059eb24-13b2b08a553so38610c88.0 for ; Tue, 30 Jun 2026 15:55:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782860139; cv=none; d=google.com; s=arc-20260327; b=Tdrv6jHuLEm4J4wLCexvsck6H2O+w3oyCeSYyDNSpunLyDtA//l+D/0gwM0AxZlh3N BWzZ28T7kY3ULvkxBDJwfguRf8pZYhCsG2JWC0VCygJZtxgx1RGr8DsJuc8kPOBJHdF7 VIJWU4Q3BQJg+2yWCt7VTSpYIFITknTHd8ueLmmMiyPUcx9i7FDR/eui9kAe+xO18JTJ inqEITVAJg4Wjm0i5EcSXO7y72GO6J45zH17lAw6huAgmFqAY1tDzwZ1KY+PuIIKOt+O Udo6UhevKMeVlk7sw5pCn8a1hXlbZJjQRKEIhdqk1rBJwW52OT8BidyzDgdIdzqwxqa3 melw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0ufRs7jbz+7zNErx/AfaA1flmtddekdRBnIktmT56h4=; fh=8PJ6tX0NgYSc315o0vIUccs9RDubm/THlYl6WlG8bJo=; b=EKmYlW5G9Gfm1j4+Dzp2TxUZhQD4Li4q2llG8ZJnqFy4OZ12kUTy8hMf9YYkseIqdf Fap4O7jcfKmIVJVO0JB/tamwdNeldU3SSPsyf56mWboyWLnkCKQEOQ0ecKgDBO5YnqlO Yb6HZub+8+bVJ36Qoyjl1hOQsBEoKlXfSSacrw0rF59VJySIcLL96VYOVoz/0QEMtQ3l qBMGDT0PR1tTCAwc5/n7c24scHM1SJjCdgqz+hytaBt99RGM8j+KRtnapknnk2T7F+Qi pFnlTEofCBEFCgtNQvEhlDJw8kDhBgYrCr5aEBN9YKqgGd8vQG/jAE9GXAv4oJp7uexv N/GA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1782860139; x=1783464939; darn=vger.kernel.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=0ufRs7jbz+7zNErx/AfaA1flmtddekdRBnIktmT56h4=; b=jwwkbQXU4plCk5JPPjsZMQJtgmoKYDljp3tD7DbdHQlzG3IdLItQLVD2HTaoTSX55P jjqI+LGZESKqQ7OEkZGeigyS5L0axr7d48WbZ2n5SS0H4Jtz65T3A4sWT/hBQFlsH1k1 rBbzdIYQqAS6kPeWMZ3o25AJcCVdjAodAIz2nN5H7fV2+vi3V/Vte4RsMnojLSC1XbT+ kIVnEFn+UzatYa2ex41llL4cu7vfsVyQOLmPygrMNhe0rMoNp5adxqrRi+x4OYbUp9T0 UEPm3O/cMZ8TmORoGwiAt6pebfDoHJ8yleHmv+VD7iC2odlLbEA2cA7VTFc9pwEprfLx kafg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782860139; x=1783464939; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0ufRs7jbz+7zNErx/AfaA1flmtddekdRBnIktmT56h4=; b=i1xIiXD7E8ZTbGoao51ug6V/7U5FghtTsF8xps8hLlJSIT0Q/s3c/RPpzNApWGNern /SFVodmQjhNHrw3lcjClEdaiToQoFVjvbJoLph89r6P8omcifcJr5mGeowBbw9G7fWOi nJ1b4GnspIGawo8OUaISdzRnPTVsEYJu8Ip0dO/RmtoEszePtjVEwBkVpG7XY14QfVQ8 1Nmn+Z5JnzliL6phk2F2TNS8PiVX/s6orlTD6GdmX55XOt1gzdQTaRlbAJtIW388+ZgQ W1CgoK3VQjAHqCBtBFm8OJ+gFmo7tnjAG2NY3HWxyAfmUwW6rNvC1NsgoTeU0DgIxg3p Mw7Q== X-Forwarded-Encrypted: i=1; AFNElJ+I+PRCDoK172/khXO1jbcOoB0mXdOI16MGVQ0yxmEeYPMihZrebSpuO8z3idlbuh3Xw7s5asyjv6Ftqho=@vger.kernel.org X-Gm-Message-State: AOJu0YypBGOJNFaOOja8XPeyZKpV4/VNTSa/26YITLYQCUimlSPRG1Ul 0+4ypMZfJGNiKKIVDaqCvJZ/KbL9ig21h6RSKwtb+8wGy7v7YcyX5xyjVSpftRo5l4+JSgiuMZU JK3HC0fGH3cDWcRMGkMr95TsPsx+t/N1HA9adYBPm X-Gm-Gg: AfdE7clgT4OvY5b+AjxGTrljDO2rnq5kTHe+zkQj6smO1j7pvo5ZsVxq6p4/y5fQCaa xp98a9oyEjxxy+ghovXtmdejkPBhFwlSLYczwNAF79mEM3vS5Huee0Eb1G1kC7T/GbPNa9yBT/h 0W6IsQm2EQm4aYIbAK0VJwrmsUBuoX8pJT33pWgujCdKQER2171rCzZwo5vPpbdgw4kFCFwD+Z9 osBsCCflqmkwuce7lP7kCqeLHQm8gpa8byGdK4rm0CMY+DQDIQE03SuYQHUCSDOYkPcURCd X-Received: by 2002:a05:7022:60a:b0:139:ed5d:1b5a with SMTP id a92af1059eb24-13b2a1c0f41mr3645093c88.40.1782860138109; Tue, 30 Jun 2026 15:55:38 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260625054946.73445-1-duanchenghao@kylinos.cn> <20260625054946.73445-2-duanchenghao@kylinos.cn> <2vxzfr2bkn0j.fsf@kernel.org> <20260629100621.GA215869@chenghao-pc> In-Reply-To: <20260629100621.GA215869@chenghao-pc> From: David Matlack Date: Tue, 30 Jun 2026 15:55:11 -0700 X-Gm-Features: AVVi8CdC-YicerQYwyKKogj1zQs5YRNCTCvCtXWkU5DiVwwhFHMSMIyXZ1dV4nA Message-ID: Subject: Re: [PATCH v1 1/2] eventfd: luo: luo support for preserving eventfd To: Chenghao Duan Cc: Pratyush Yadav , viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org, rppt@kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, jianghaoran@kylinos.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2026 at 3:06=E2=80=AFAM Chenghao Duan wrote: > > On Thu, Jun 25, 2026 at 11:06:04AM +0200, Pratyush Yadav wrote: > > On Thu, Jun 25 2026, Chenghao Duan wrote: > > > > > This patch adds support for preserving eventfd file descriptors acros= s > > > kexec live updates using the Live Update Orchestrator (LUO) framework= . > > > Userspace applications using eventfd for event notification can now > > > maintain their state across kernel updates. > > > > > > Preserved State: > > > The following properties of the eventfd are preserved across kexec: > > > - Counter Value: The current 64-bit counter value, including any pend= ing > > > events that have been signaled but not yet consumed by readers. > > > - File Flags: The creation flags (EFD_SEMAPHORE, EFD_CLOEXEC, EFD_NON= BLOCK) > > > are preserved. > > > > > > Non-Preserved State: > > > - File Descriptor Number: The eventfd will be assigned a new fd numbe= r > > > in the target process after restore. > > > - Wait Queue State: Any processes blocked on read() operations will b= e > > > woken up and need to re-establish their blocking state. > > > - All other internal state is reset to default. > > > > > > Changes: > > > - fs/eventfd.c: Add eventfd_luo_get_state() to safely read eventfd st= ate > > > (count and flags), and eventfd_create() helper function. > > > - fs/eventfd_luo.c: New file implementing LUO file operations: > > > preserve, freeze, unpreserve, retrieve, and finish callbacks. > > > - include/linux/eventfd.h: Export new functions. > > > - include/linux/kho/abi/eventfd.h: Define the ABI contract with > > > eventfd_luo_ser structure for serialization. > > > > Why do you need to preserve this? Why don't you create a fresh one afte= r > > kexec? You just preserve the counter, which looks pretty much useless. > > You can just as well open a new eventfd after kexec and set the counter > > value if you care about it. > > Thank you very much for your review and suggestions. > > My original plan was to integrate KVM with eventfd. Eventfd serves as a > critical notification mechanism between guest and host, and it is widely > adopted in various scenarios such as networking, file systems, and > interrupt handling. > > At present, however, I have only implemented the preserve and retrieve > logic for eventfd, and the integration with KVM has not yet been > completed. > > I have a question and would greatly appreciate your help with it. > I have been closely following upstream developments for the liveupdate > feature. As I understand it, liveupdate is primarily targeted at cloud > virtual machine scenarios. The upstream community has completed the > core framework for liveupdate and memfd, and ongoing discussions are > focused on state preservation and restoration for VFIO and IOMMU. Yes that's correct, but that work is to solve some very specific problems for virtual machine scenarios: 1. memfd preservation allows preserving guest memory and userspace (e.g. VMM) state in-place across Live Update. 2. VFIO/IOMMU preservation allows PCIe devices assigned to virtual machines to keep running uninterrupted across Live Update. I think this series is missing a description of the problem solved by preserving eventfds. We don't want to preserve all types of fds just for the sake of it. That will bloat the ABI (which will make maintaining version compaitibility harder) without any gain. > > I would like to clarify the following points regarding upstream=E2=80=99s > overall roadmap for the liveupdate feature: > 1. What is the complete upstream plan for liveupdate? > 2. What will the final deliverables look like once fully implemented? > 3. Will any new kernel internal interfaces or dedicated userspace tools > be introduced? > 4. Does the upstream community maintain an official TODO list tracking > outstanding work items for liveupdate? I don't think we have anything comprehensive but there is a ton of work to be done if you are looking to help. A good first step would be to attend the bi-weekly Hypervisor Live Update meeting. See https://lore.kernel.org/kexec/aiWW6ZwwalqQmVcB@google.com/. The next one is on July 13th.