lkml.org 
[lkml]   [2023]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH v6 11/12] Docs/x86/sgx: Add description for cgroup support
    Date
    From: Sean Christopherson <sean.j.christopherson@intel.com>

    Add initial documentation of how to regulate the distribution of
    SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup
    controller.

    Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Co-developed-by: Kristen Carlson Accardi <kristen@linux.intel.com>
    Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
    Co-developed-by: Haitao Huang<haitao.huang@linux.intel.com>
    Signed-off-by: Haitao Huang<haitao.huang@linux.intel.com>
    Cc: Sean Christopherson <seanjc@google.com>
    ---
    V6:
    - Remove mentioning of VMM specific behavior on handling SIGBUS
    - Remove statement of forced reclamation, add statement to specify
    ENOMEM returned when no reclamation possible.
    - Added statements on the non-preemptive nature for the max limit
    - Dropped Reviewed-by tag because of changes

    V4:
    - Fix indentation (Randy)
    - Change misc.events file to be read-only
    - Fix a typo for 'subsystem'
    - Add behavior when VMM overcommit EPC with a cgroup (Mikko)
    ---
    Documentation/arch/x86/sgx.rst | 74 ++++++++++++++++++++++++++++++++++
    1 file changed, 74 insertions(+)

    diff --git a/Documentation/arch/x86/sgx.rst b/Documentation/arch/x86/sgx.rst
    index d90796adc2ec..dfc8fac13ab2 100644
    --- a/Documentation/arch/x86/sgx.rst
    +++ b/Documentation/arch/x86/sgx.rst
    @@ -300,3 +300,77 @@ to expected failures and handle them as follows:
    first call. It indicates a bug in the kernel or the userspace client
    if any of the second round of ``SGX_IOC_VEPC_REMOVE_ALL`` calls has
    a return code other than 0.
    +
    +
    +Cgroup Support
    +==============
    +
    +The "sgx_epc" resource within the Miscellaneous cgroup controller regulates distribution of SGX
    +EPC memory, which is a subset of system RAM that is used to provide SGX-enabled applications
    +with protected memory, and is otherwise inaccessible, i.e. shows up as reserved in /proc/iomem
    +and cannot be read/written outside of an SGX enclave.
    +
    +Although current systems implement EPC by stealing memory from RAM, for all intents and
    +purposes the EPC is independent from normal system memory, e.g. must be reserved at boot from
    +RAM and cannot be converted between EPC and normal memory while the system is running. The EPC
    +is managed by the SGX subsystem and is not accounted by the memory controller. Note that this
    +is true only for EPC memory itself, i.e. normal memory allocations related to SGX and EPC
    +memory, e.g. the backing memory for evicted EPC pages, are accounted, limited and protected by
    +the memory controller.
    +
    +Much like normal system memory, EPC memory can be overcommitted via virtual memory techniques
    +and pages can be swapped out of the EPC to their backing store (normal system memory allocated
    +via shmem). The SGX EPC subsystem is analogous to the memory subsystem, and it implements
    +limit and protection models for EPC memory.
    +
    +SGX EPC Interface Files
    +-----------------------
    +
    +For a generic description of the Miscellaneous controller interface files, please see
    +Documentation/admin-guide/cgroup-v2.rst
    +
    +All SGX EPC memory amounts are in bytes unless explicitly stated otherwise. If a value which
    +is not PAGE_SIZE aligned is written, the actual value used by the controller will be rounded
    +down to the closest PAGE_SIZE multiple.
    +
    + misc.capacity
    + A read-only flat-keyed file shown only in the root cgroup. The sgx_epc resource will
    + show the total amount of EPC memory available on the platform.
    +
    + misc.current
    + A read-only flat-keyed file shown in the non-root cgroups. The sgx_epc resource will
    + show the current active EPC memory usage of the cgroup and its descendants. EPC pages
    + that are swapped out to backing RAM are not included in the current count.
    +
    + misc.max
    + A read-write single value file which exists on non-root cgroups. The sgx_epc resource
    + will show the EPC usage hard limit. The default is "max".
    +
    + If a cgroup's EPC usage reaches this limit, EPC allocations, e.g. for page fault
    + handling, will be blocked until EPC can be reclaimed from the cgroup. If there are no
    + pages left that are reclaimable within the same group, the kernel returns ENOMEM.
    +
    + The EPC pages allocated for a guest VM by the virtual EPC driver are not reclaimable by
    + the host kernel. In case the guest cgroup's limit is reached and no reclaimable pages
    + left in the same cgroup, the virtual EPC driver returns SIGBUS to the user space
    + process to indicate failure on new EPC allocation requests.
    +
    + The misc.max limit is non-preemptive. If a user writes a limit lower than the current
    + usage to this file, the cgroup will not preemptively deallocate pages currently in use,
    + and will only start blocking the next allocation and reclaiming EPC at that time.
    +
    + misc.events
    + A read-only flat-keyed file which exists on non-root cgroups.
    + A value change in this file generates a file modified event.
    +
    + max
    + The number of times the cgroup has triggered a reclaim
    + due to its EPC usage approaching (or exceeding) its max
    + EPC boundary.
    +
    +Migration
    +---------
    +
    +Once an EPC page is charged to a cgroup (during allocation), it remains charged to the original
    +cgroup until the page is released or reclaimed. Migrating a process to a different cgroup
    +doesn't move the EPC charges that it incurred while in the previous cgroup to its new cgroup.
    --
    2.25.1
    \
     
     \ /
      Last update: 2023-10-30 19:22    [W:4.189 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site