Messages in this thread | | | Date | Thu, 1 Jun 2023 16:58:09 -0700 | Subject | Re: [RFC v3 00/21] Preserved-over-Kexec RAM | From | Anthony Yznaga <> |
| |
On 5/31/23 7:15 PM, Baoquan He wrote: > On 04/26/23 at 05:08pm, Anthony Yznaga wrote: >> Sending out this RFC in part to guage community interest. >> This patchset implements preserved-over-kexec memory storage or PKRAM as a >> method for saving memory pages of the currently executing kernel so that >> they may be restored after kexec into a new kernel. The patches are adapted >> from an RFC patchset sent out in 2013 by Vladimir Davydov [1]. They >> introduce the PKRAM kernel API. >> >> One use case for PKRAM is preserving guest memory and/or auxillary >> supporting data (e.g. iommu data) across kexec to support reboot of the >> host with minimal disruption to the guest. PKRAM provides a flexible way >> for doing this without requiring that the amount of memory used by a fixed >> size created a priori. Another use case is for databases to preserve their >> block caches in shared memory across reboot. > If so, I have confusions, who can help clarify: > 1) Why kexec reboot was introduced, what do we expect kexec reboot to > do? > > 2) If we need keep these data and those data, can we not reboot? They > are definitely located there w/o any concern. > > 3) What if systems of AI, edge computing, HPC etc also want to carry > kinds of data from userspace or kernel, system status, registers > etc when kexec reboot is needed, while enligntened by this patch?
Hi Baoquan,
Avoiding a more significant disruption from having to halt or migrate
VMs, failover services, etc. when a reboot is necessary to pick up
security fixes is one motivation for exploring preserving memory
across the reboot.
Anthony
> > Thanks > Baoquan >
| |