From: Jason Gunthorpe <jgg@nvidia.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: "Li Chen" <me@linux.beauty>, "Peter Xu" <peterx@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Laurent Vivier" <lvivier@redhat.com>,
"David Hildenbrand" <david@kernel.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>,
"David Matlack" <dmatlack@google.com>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Alexander Graf" <graf@amazon.com>,
"Samiullah Khawaja" <skhawaja@google.com>
Subject: Re: [PATCH 0/3] CPR: shared RAM with /dev/fdset for LUO kexec reboot
Date: Fri, 2 Jan 2026 11:39:57 -0400 [thread overview]
Message-ID: <20260102153957.GA125162@nvidia.com> (raw)
In-Reply-To: <CA+CK2bC0N7v7MnC6LybAzE_oJPWeWK0v9xVng-JgEnvC6ay+nQ@mail.gmail.com>
On Tue, Dec 30, 2025 at 11:42:09AM -0500, Pasha Tatashin wrote:
> > One question: in the intended LUOD/session architecture, do you still expect
> > clients (or a wrapper) to inject the retrieved guest RAM memfd FD into QEMU
> > via -add-fd + /dev/fdset/<id> at QEMU startup? (as this patchset does)
> >
> > Or is the longer-term plan that QEMU itself connects to LUOD over UDS, retrieves
> > the session/resource FD directly, and consumes it as the RAM backing without
> > going through -add-fd?
>
> The latter, I expect QEMU and other VMMs use their LUO session FDs
> that they receive from LUOD to retrieve and restore the preserved
> resources: memfd+iommufd+vfiofd and resume the suspended VMs.
Right, and we shouldn't have something like /dev/fset/ID at all.
The VMM has to know it is doing a LUO restoration and squence
restoration of all the stuff the preserving VMM put into LUO.
The general case is far more complex than just opening a memfd.
Jason
prev parent reply other threads:[~2026-01-02 15:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 12:08 [PATCH 0/3] CPR: shared RAM with /dev/fdset for LUO kexec reboot Li Chen
2025-12-29 12:08 ` [PATCH 1/3] system/physmem: allow /dev/fdset for file-backed RAM Li Chen
2025-12-29 12:08 ` [PATCH 2/3] docs: CPR: document shared RAM with x-ignore-shared Li Chen
2025-12-29 12:08 ` [PATCH 3/3] tests/qtest: cpr-reboot: check ignore-shared transfer Li Chen
2025-12-29 15:50 ` [PATCH 0/3] CPR: shared RAM with /dev/fdset for LUO kexec reboot Pasha Tatashin
2025-12-30 8:30 ` Li Chen
2025-12-30 16:42 ` Pasha Tatashin
2026-01-02 15:39 ` Jason Gunthorpe [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260102153957.GA125162@nvidia.com \
--to=jgg@nvidia.com \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=farosas@suse.de \
--cc=graf@amazon.com \
--cc=lvivier@redhat.com \
--cc=me@linux.beauty \
--cc=pasha.tatashin@soleen.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=pratyush@kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.