lkml.org 
[lkml]   [2023]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC v3 00/21] Preserved-over-Kexec RAM
    From

    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
    >

    \
     
     \ /
      Last update: 2023-06-02 01:59    [W:3.984 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site