Re: [RFC v3 00/21] Preserved-over-Kexec RAM

[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