On 1/05/2024 7:51 am, Haitao Huang wrote:
static void sgx_reclaim_pages_global(struct mm_struct *charge_mm)
{
- sgx_reclaim_pages(_global_lru, charge_mm);
+ if (IS_ENABLED(CONFIG_CGROUP_MISC))
+ sgx_cgroup_reclaim_pages(misc_cg_root(), charge_mm);
+ else
On 1/05/2024 7:51 am, Haitao Huang wrote:
From: Kristen Carlson Accardi
For the global reclaimer to determine if any page available for
reclamation at the global level, it currently only checks for emptiness
of the global LRU. That will be inadequate when pages are tracked in
multiple LRUs,
/*
@@ -42,7 +63,8 @@ static inline struct sgx_epc_lru_list
*sgx_lru_list(struct sgx_epc_page *epc_pag
*/
static inline bool sgx_can_reclaim(void)
{
- return !list_empty(_global_lru.reclaimable);
+ return !sgx_cgroup_lru_empty(misc_cg_root()) ||
+
> +/*
> + * Get the per-cgroup or global LRU list that tracks the given reclaimable
> page.
> + */
> static inline struct sgx_epc_lru_list *sgx_lru_list(struct sgx_epc_page
> *epc_page)
> {
> +#ifdef CONFIG_CGROUP_MISC
> + /*
> + * epc_page->sgx_cg here is never NULL during a
On Tue, 2024-04-23 at 19:26 -0500, Haitao Huang wrote:
> On Tue, 23 Apr 2024 17:13:15 -0500, Huang, Kai wrote:
>
> > On Tue, 2024-04-23 at 10:30 -0500, Haitao Huang wrote:
> > > > > It's a workaround because you use the capacity==0 but it does not
> > &
On Wed, 2024-04-24 at 00:27 +0300, Jarkko Sakkinen wrote:
> On Tue Apr 23, 2024 at 8:08 PM EEST, Reinette Chatre wrote:
> > Hi Kai,
> >
> > On 4/23/2024 4:50 AM, Huang, Kai wrote:
> > > > diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c
> > > > b/
On Tue, 2024-04-23 at 10:30 -0500, Haitao Huang wrote:
> > > It's a workaround because you use the capacity==0 but it does not really
> > > mean to disable the misc cgroup for specific resource IIUC.
> >
> > Please read the comment around @misc_res_capacity again:
> >
> > * Miscellaneous
On Tue, 2024-04-23 at 08:08 -0500, Haitao Huang wrote:
> On Mon, 22 Apr 2024 17:16:34 -0500, Huang, Kai wrote:
>
> > On Mon, 2024-04-22 at 11:17 -0500, Haitao Huang wrote:
> > > On Sun, 21 Apr 2024 19:22:27 -0500, Huang, Kai
> > > wrote:
> > >
&g
On Tue, 2024-04-23 at 17:25 +0800, 朱伯君(杰铭) wrote:
> EDMM's ioctl()s support batch operations, which may be
> time-consuming. Try to explicitly give up the CPU at
> the every end of "for loop" in
> sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
> to give other tasks a chance to
On Mon, 2024-04-15 at 20:20 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> Add initial documentation of how to regulate the distribution of
> SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup
> controller.
>
>
Acked-by: Kai Huang
On Mon, 2024-04-15 at 20:20 -0700, Haitao Huang wrote:
> Enclave Page Cache(EPC) memory can be swapped out to regular system
> memory, and the consumed memory should be charged to a proper
> mem_cgroup. Currently the selection of mem_cgroup to charge is done in
> sgx_encl_get_mem_cgroup(). But it
On Mon, 2024-04-22 at 11:17 -0500, Haitao Huang wrote:
> On Sun, 21 Apr 2024 19:22:27 -0500, Huang, Kai wrote:
>
> > On Fri, 2024-04-19 at 20:14 -0500, Haitao Huang wrote:
> > > > > I think we can add support for "sgx_cgroup=disabled" in future if
&g
On Fri, 2024-04-19 at 20:14 -0500, Haitao Huang wrote:
> > > I think we can add support for "sgx_cgroup=disabled" in future if indeed
> > > needed. But just for init failure, no?
> > >
> >
> > It's not about the commandline, which we can add in the future when
> > needed. It's about we need to
On Fri, 2024-04-19 at 13:55 -0500, Haitao Huang wrote:
> On Thu, 18 Apr 2024 20:32:14 -0500, Huang, Kai wrote:
>
> >
> >
> > On 16/04/2024 3:20 pm, Haitao Huang wrote:
> > > From: Kristen Carlson Accardi
> > > In cases EPC pages need be al
> Documentation of task_get_css() says it always
> returns a valid css. This function is used by get_current_misc_cg() to get
> the css refernce.
>
>
> /**
> * task_get_css - find and get the css for (task, subsys)
> * @task: the target task
> * @subsys_id: the target subsystem ID
>
On 16/04/2024 3:20 pm, Haitao Huang wrote:
From: Kristen Carlson Accardi
In cases EPC pages need be allocated during a page fault and the cgroup
usage is near its limit, an asynchronous reclamation needs be triggered
to avoid blocking the page fault handling.
Create a workqueue,
Was requested by Jarkko:
https://lore.kernel.org/lkml/CYU504RLY7QU.QZY9LWC076NX@suppilovahvero/#t
[...]
Ah I missed that. No problem to me.
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SGX_EPC_CGROUP_H_
On 16/04/2024 3:20 pm, Haitao Huang wrote:
From: Kristen Carlson Accardi
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This is not ideal. When that happens, a better way is
to
On Mon, 2024-04-15 at 20:20 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The functions, sgx_{mark,unmark}_page_reclaimable(), manage the tracking
> of reclaimable EPC pages: sgx_mark_page_reclaimable() adds a newly
> allocated page into the global LRU list while
>
On Mon, 2024-04-15 at 20:20 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> SGX Enclave Page Cache (EPC) memory allocations are separate from normal
> RAM allocations, and are managed solely by the SGX subsystem. The
> existing cgroup memory controller cannot be used to limit or
>
> I'll send a fixup for this patch or another version of the series if more
> changes are needed.
Hi Haitao,
I don't like to say but in general I think you are sending too frequently. The
last version was sent April, 11th (my time), so considering the weekend it has
only been 3 or at most
On Wed, 2024-04-10 at 11:25 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> Introduce a data structure to wrap the existing reclaimable list and its
> spinlock. Each cgroup later will have one instance of this structure to
> track EPC pages allocated for processes associated with the
On Wed, 2024-04-10 at 11:25 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
> for the misc controller.
>
> Signed-off-by: Kristen Carlson Accardi
> Co-developed-by: Haitao Huang
> Signed-off-by: Haitao Huang
On Wed, 2024-04-10 at 11:25 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The SGX EPC cgroup will reclaim EPC pages when usage in a cgroup reaches
> its or ancestor's limit. This requires a walk from the current cgroup up
> to the root similar to misc_cg_try_charge(). Export
On Wed, 2024-04-10 at 11:25 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> The misc cgroup controller (subsystem) currently does not perform
> resource type specific action for Cgroups Subsystem State (CSS) events:
> the 'css_alloc' event when a cgroup is created and the
On Wed, 2024-04-10 at 11:25 -0700, Haitao Huang wrote:
> Replace boolean parameters for 'reclaim' in the function
> sgx_alloc_epc_page() and its callers with an enum.
>
> Also opportunistically remove non-static declaration of
> __sgx_alloc_epc_page() and a typo
>
> Signed-off-by: Haitao Huang
On 9/04/2024 6:03 am, Haitao Huang wrote:
The misc root cgroup is a static similar to sgx_cg_root. So
misc_cg_root() won't be NULL
However, based on how css_misc() was check NULL, I suppose
sgx_get_current_cg() may be NULL when cgroup is disabled (again not 100%
sure but we handle it
> --- a/arch/x86/kernel/cpu/sgx/epc_cgroup.h
> +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.h
> @@ -28,6 +28,10 @@ static inline int sgx_cgroup_try_charge(struct sgx_cgroup
> *sgx_cg, enum sgx_recl
> static inline void sgx_cgroup_uncharge(struct sgx_cgroup *sgx_cg) { }
>
> static inline void
On Thu, 2024-04-04 at 12:05 -0500, Haitao Huang wrote:
> > > -static inline int sgx_cgroup_try_charge(struct sgx_cgroup *sgx_cg)
> > > +static inline int sgx_cgroup_try_charge(struct sgx_cgroup *sgx_cg,
> > > enum sgx_reclaim r)
> >
> > Is the @r here intentional for shorter typing?
> >
>
>
On Thu, 2024-04-04 at 12:05 -0500, Haitao Huang wrote:
> > Please also mention why "leaving asynchronous reclamation to later
> > patch(es)" is
> > fine. E.g., it won't break anything I suppose.
> >
>
> Right. Pages are still in the global list at the moment and only global
> reclaiming is
On Thu, 2024-04-04 at 20:24 -0500, Haitao Huang wrote:
> > Again, IMHO having CONFIG_CGROUP_SGX_EPC here is ugly, because it
> > doesn't even
> > match the try_charge() above, which doesn't have the
> > CONFIG_CGROUP_SGX_EPC.
> >
> > If you add a wrapper in "epc_cgroup.h"
> >
> Agree. but in
On Wed, 2024-03-27 at 17:22 -0700, Haitao Huang wrote:
>
> void sgx_cgroup_init(void)
> {
> + sgx_cg_wq = alloc_workqueue("sgx_cg_wq", WQ_UNBOUND | WQ_FREEZABLE,
> WQ_UNBOUND_MAX_ACTIVE);
> +
> + /* All Cgroups functionalities are disabled. */
> + if (WARN_ON(!sgx_cg_wq))
> +
On Wed, 2024-03-27 at 17:22 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When a cgroup usage reaches its limit, and it is to be charged, i.e.,
> sgx_cgroup_try_charge() called for new allocations, the cgroup needs to
> reclaim pages from its LRU or LRUs of its descendants to
On Sat, 2024-03-30 at 13:17 +0200, Jarkko Sakkinen wrote:
> On Thu Mar 28, 2024 at 2:53 PM EET, Huang, Kai wrote:
> >
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> > > @@ -0,0 +1,74 @@
> > > +// SPDX-License-Identifi
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.c
> @@ -0,0 +1,74 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright(c) 2022 Intel Corporation.
It's 2024 now.
And looks you need to use C style comment for /* Copyright ... */, after looking
at some other C files.
> +
>
On 27/02/2024 11:38 am, Dave Hansen wrote:
On 2/26/24 14:34, Huang, Kai wrote:
So I am trying to get the actual downside of doing per-cgroup reclaim or
the full reason that we choose global reclaim.
Take the most extreme example:
while (hit_global_sgx_limit
On 27/02/2024 11:31 am, Dave Hansen wrote:
On 2/26/24 14:24, Huang, Kai wrote:
What is the downside of doing per-group reclaim when try_charge()
succeeds for the enclave but failed to allocate EPC page?
Could you give an complete answer why you choose to use global reclaim
for the above
Kai, I think your examples sound a little bit contrived. Have actual
users expressed a strong intent for doing anything with this series
other than limiting bad actors from eating all the EPC?
I am not sure about this. I am also trying to get a full picture.
I asked because I didn't quite
On 27/02/2024 10:18 am, Haitao Huang wrote:
On Mon, 26 Feb 2024 05:36:02 -0600, Huang, Kai wrote:
On Sun, 2024-02-25 at 22:03 -0600, Haitao Huang wrote:
On Sun, 25 Feb 2024 19:38:26 -0600, Huang, Kai
wrote:
>
>
> On 24/02/2024 6:00 am, Haitao Huang wrote:
> > On Fri, 23
On Sun, 2024-02-25 at 22:03 -0600, Haitao Huang wrote:
> On Sun, 25 Feb 2024 19:38:26 -0600, Huang, Kai wrote:
>
> >
> >
> > On 24/02/2024 6:00 am, Haitao Huang wrote:
> > > On Fri, 23 Feb 2024 04:18:18 -0600, Huang, Kai
> > > wrote:
> > &g
On 24/02/2024 6:00 am, Haitao Huang wrote:
On Fri, 23 Feb 2024 04:18:18 -0600, Huang, Kai wrote:
>
Right. When code reaches to here, we already passed reclaim per cgroup.
Yes if try_charge() failed we must do pre-cgroup reclaim.
The cgroup may not at or reach limit but system has
> >
> Right. When code reaches to here, we already passed reclaim per cgroup.
Yes if try_charge() failed we must do pre-cgroup reclaim.
> The cgroup may not at or reach limit but system has run out of physical
> EPC.
>
But after try_charge() we can still choose to reclaim from the current
On 23/02/2024 5:36 am, Haitao Huang wrote:
On Wed, 21 Feb 2024 05:23:00 -0600, Huang, Kai wrote:
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
From: Kristen Carlson Accardi
Previous patches have implemented all infrastructure needed for
per-cgroup EPC page tracking
On 23/02/2024 6:20 am, Haitao Huang wrote:
On Wed, 21 Feb 2024 05:00:27 -0600, Huang, Kai wrote:
On Wed, 2024-02-21 at 00:44 -0600, Haitao Huang wrote:
[...]
>
> Here the @nr_to_scan is reduced by the number of pages that are
> isolated, but
> not actually reclaimed (which
On 23/02/2024 9:12 am, Haitao Huang wrote:
On Wed, 21 Feb 2024 04:48:58 -0600, Huang, Kai wrote:
On Wed, 2024-02-21 at 00:23 -0600, Haitao Huang wrote:
StartHi Kai
On Tue, 20 Feb 2024 03:52:39 -0600, Huang, Kai
wrote:
[...]
>
> So you introduced the work/workqueue here but t
On 23/02/2024 6:09 am, Haitao Huang wrote:
On Wed, 21 Feb 2024 05:06:02 -0600, Huang, Kai wrote:
-int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg)
+int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg, bool
reclaim)
{
- return misc_cg_try_charge
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> To determine if any page available for reclamation at the global level,
> only checking for emptiness of the global LRU is not adequate when pages
> are tracked in multiple LRUs, one per cgroup. For this
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Previous patches have implemented all infrastructure needed for
> per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
> pages are still tracked in the global LRU as sgx_lru_list() returns
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When cgroup is enabled, all reclaimable pages will be tracked in cgroup
> LRUs. The global reclaimer needs to start reclamation from the root
> cgroup. Expose the top level cgroup reclamation function so
> -int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg)
> +int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg, bool reclaim)
> {
> - return misc_cg_try_charge(MISC_CG_RES_SGX_EPC, epc_cg->cg, PAGE_SIZE);
> + for (;;) {
> + if
On Wed, 2024-02-21 at 00:44 -0600, Haitao Huang wrote:
> [...]
> >
> > Here the @nr_to_scan is reduced by the number of pages that are
> > isolated, but
> > not actually reclaimed (which is reflected by @cnt).
> >
> > IIUC, looks you want to make this function do "each cycle" as what you
> >
On Wed, 2024-02-21 at 00:23 -0600, Haitao Huang wrote:
> StartHi Kai
> On Tue, 20 Feb 2024 03:52:39 -0600, Huang, Kai wrote:
> [...]
> >
> > So you introduced the work/workqueue here but there's no place which
> > actually
> > queues the work. IMHO you can
On Tue, 2024-02-20 at 14:18 +0100, Michal Koutný wrote:
> On Tue, Feb 20, 2024 at 09:52:39AM +, "Huang, Kai"
> wrote:
> > I am not sure, but is it possible or legal for an ancestor to have less
> > limit
> > than children?
>
> Why not?
> It i
> +/*
> + * Get the lower bound of limits of a cgroup and its ancestors. Used in
> + * sgx_epc_cgroup_reclaim_work_func() to determine if EPC usage of a cgroup
> is
> + * over its limit or its ancestors' hence reclamation is needed.
> + */
> +static inline u64
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Sean Christopherson
>
> Each EPC cgroup will have an LRU structure to track reclaimable EPC pages.
> When a cgroup usage reaches its limit, the cgroup needs to reclaim pages
> from its LRU or LRUs of its descendants to make room for
> + * @lru: The LRU from which pages are reclaimed.
> + * @nr_to_scan: Pointer to the target number of pages to scan, must be less
> than
> + * SGX_NR_TO_SCAN.
> + * Return: Number of pages reclaimed.
> */
> -static void sgx_reclaim_pages(void)
> +unsigned int
> struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim) {
> + struct sgx_epc_cgroup *epc_cg;
> struct sgx_epc_page *page;
> + int ret;
> +
> + epc_cg = sgx_get_current_epc_cg();
> + ret = sgx_epc_cgroup_try_charge(epc_cg);
> + if (ret) {
> +
>
> Signed-off-by: Haitao Huang
> Reported-by: Mikko Ylinen
> ---
Non-technical staff:
I believe checkpatch requires you to have a "Closes" tag after "Reported-by"
otherwise it complains something like this:
WARNING: Reported-by: should be immediately followed by Closes: with a URL
to
On Sat, 2023-12-16 at 09:16 -0800, Randy Dunlap wrote:
> Don't use "/**" for a non-kernel-doc comment. This prevents a warning
> from scripts/kernel-doc:
>
> main.c:740: warning: expecting prototype for A section metric is concatenated
> in a way that @low bits 12(). Prototype was for
> >
> > The point is, with or w/o this patch, you can only reclaim 16 EPC pages
> > in one
> > function call (as you have said you are going to remove
> > SGX_NR_TO_SCAN_MAX,
> > which is a cipher to both of us). The only difference I can see is,
> > with this
> > patch, you can have
On Mon, 2023-12-11 at 22:04 -0600, Haitao Huang wrote:
> Hi Kai
>
> On Mon, 27 Nov 2023 03:57:03 -0600, Huang, Kai wrote:
>
> > On Mon, 2023-11-27 at 00:27 +0800, Haitao Huang wrote:
> > > On Mon, 20 Nov 2023 11:45:46 +0800, Huang, Kai
> > > wrote:
> &
On Mon, 2023-11-27 at 00:27 +0800, Haitao Huang wrote:
> On Mon, 20 Nov 2023 11:45:46 +0800, Huang, Kai wrote:
>
> > On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
> > > From: Sean Christopherson
> > >
> > > To prepare for per-cgroup recl
On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> To prepare for per-cgroup reclamation, separate the top-level reclaim
> function, sgx_reclaim_epc_pages(), into two separate functions:
>
> - sgx_isolate_epc_pages() scans and isolates reclaimable pages from
> > >
> >
> > That's true. I was thinking no need to have them done in separate calls.
> > The caller has to check the return value for epc_cg instance first, then
> > check result of try_charge. But there is really only one caller,
> > sgx_alloc_epc_page() below, so I don't have strong
> I should have sticked to the orignial comment added in code. Actually
> __sgx_alloc_epc_page() can fail if system runs out of EPC. That's the really
> reason
> for global reclaim. The free count enforcement is near the end of this method
> after should_reclaim() check.
Hi Haitao,
Sorry I have
On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
> +static int __init sgx_epc_cgroup_init(void)
> +{
> + struct misc_cg *cg;
> +
> + if (!boot_cpu_has(X86_FEATURE_SGX))
> + return 0;
> +
> + cg = misc_cg_root();
> + BUG_ON(!cg);
> +
> + return
>
> > > +/**
> > > + * sgx_epc_cgroup_try_charge() - hierarchically try to charge a single
> > > EPC page
> > > + *
> > > + * Returns EPC cgroup or NULL on success, -errno on failure.
> > > + */
> > > +struct sgx_epc_cgroup *sgx_epc_cgroup_try_charge(void)
> > > +{
> > > + struct sgx_epc_cgroup
On Mon, 2023-10-30 at 11:20 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement support for cgroup control of SGX Enclave Page Cache (EPC)
> memory using the misc cgroup controller. EPC memory is independent
> from normal system memory, e.g. must be reserved at boot from RAM
On Mon, 2023-10-16 at 19:10 -0500, Haitao Huang wrote:
> On Mon, 16 Oct 2023 16:09:52 -0500, Huang, Kai wrote:
> [...]
>
> > still need to fix the bug mentioned above here.
> >
> > I really think you should just go this simple way:
> >
> > When you wan
>
>
> From this perspective, I think the current implementation is
> "well-defined": EPC cgroup limits for VMs are only enforced at VM launch
> time, not runtime. In practice, SGX VM can be launched only with fixed
> EPC size and all those EPCs are fully committed to the VM once
On Wed, 2023-10-11 at 01:14 +, Huang, Kai wrote:
> On Tue, 2023-10-10 at 11:49 -0500, Haitao Huang wrote:
> > >
> > > This patch adds SGX_ENCL_NO_MEMORY. I guess we can use it for virtual
> > > EPC too?
> > >
> >
> > That flag is set fo
On Thu, 2023-10-12 at 08:27 -0500, Haitao Huang wrote:
> On Tue, 10 Oct 2023 19:51:17 -0500, Huang, Kai wrote:
> [...]
> > (btw, even you track VA/SECS pages in unreclaimable list, given they
> > both have
> > 'enclave' as the owner, do you still
On Tue, 2023-10-10 at 11:49 -0500, Haitao Huang wrote:
> >
> > This patch adds SGX_ENCL_NO_MEMORY. I guess we can use it for virtual
> > EPC too?
> >
>
> That flag is set for enclaves, do you mean we set similar flag in vepc
> struct?
Yes.
On Tue, 2023-10-10 at 11:49 -0500, Haitao Huang wrote:
> On Mon, 09 Oct 2023 20:34:29 -0500, Huang, Kai wrote:
>
> > On Tue, 2023-10-10 at 00:50 +0000, Huang, Kai wrote:
> > > On Mon, 2023-10-09 at 17:23 -0700, Sean Christopherson wrote:
> > > > On M
On Tue, 2023-10-10 at 12:05 -0500, Haitao Huang wrote:
> On Mon, 09 Oct 2023 21:12:27 -0500, Huang, Kai wrote:
>
> >
> > > > > >
> > > > > Later the hosting process could migrated/reassigned to another
> > > c
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> Implement support for cgroup control of SGX Enclave Page Cache (EPC)
> memory using the misc cgroup controller. EPC memory is independent
> from normal system memory, e.g. must be reserved at boot from RAM
> +
> +static inline struct sgx_epc_cgroup *sgx_epc_cgroup_from_misc_cg(struct
> misc_cg *cg)
> +{
> + if (cg)
> + return (struct sgx_epc_cgroup
> *)(cg->res[MISC_CG_RES_SGX_EPC].priv);
> +
> + return NULL;
> +}
> +
>
Is it good idea to allow passing a NULL @cg to this
On Mon, 2023-10-09 at 20:42 -0500, Haitao Huang wrote:
> Hi Sean
>
> On Mon, 09 Oct 2023 19:23:04 -0500, Sean Christopherson
> wrote:
>
> > On Mon, Oct 09, 2023, Kai Huang wrote:
> > > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > > +/**
> > > > + * sgx_epc_oom() - invoke EPC
> > > >
> > > Later the hosting process could migrated/reassigned to another cgroup?
> > > What to do when the new cgroup is OOM?
> > >
> >
> > You addressed in the documentation, no?
> >
> > +Migration
> > +-
> > +
> > +Once an EPC page is charged to a cgroup (during allocation), it
On Tue, 2023-10-10 at 00:50 +, Huang, Kai wrote:
> On Mon, 2023-10-09 at 17:23 -0700, Sean Christopherson wrote:
> > On Mon, Oct 09, 2023, Kai Huang wrote:
> > > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > > +/**
> > > > + * sgx_epc
On Mon, 2023-10-09 at 20:04 -0500, Haitao Huang wrote:
> On Mon, 09 Oct 2023 18:45:06 -0500, Huang, Kai wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > From: Sean Christopherson
> > >
> > > Introduce the OOM path
On Mon, 2023-10-09 at 17:23 -0700, Sean Christopherson wrote:
> On Mon, Oct 09, 2023, Kai Huang wrote:
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > +/**
> > > + * sgx_epc_oom() - invoke EPC out-of-memory handling on target LRU
> > > + * @lru: LRU that is low
> > > + *
> > > + *
> @@ -332,6 +336,7 @@ void sgx_isolate_epc_pages(struct sgx_epc_lru_lists *lru,
> size_t nr_to_scan,
> * sgx_reclaim_epc_pages() - Reclaim EPC pages from the consumers
> * @nr_to_scan: Number of EPC pages to scan for reclaim
> * @ignore_age: Reclaim a page even
> +static inline struct sgx_epc_lru_lists *epc_cg_lru(struct sgx_epc_cgroup
> *epc_cg)
> +{
> + if (epc_cg)
> + return _cg->lru;
> + return NULL;
> +}
>
It's legal to return NULL EPC cgroup for a given EPC page, i.e., when the
enclave isn't assigned to any cgroup. But ...
> +/**
> + * sgx_epc_cgroup_lru_empty() - check if a cgroup tree has no pages on its
> lrus
> + * @root:root of the tree to check
> + *
> + * Return: %true if all cgroups under the specified root have empty LRU
> lists.
> + * Used to avoid livelocks due to a cgroup having a non-zero charge
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> Introduce the OOM path for killing an enclave with a reclaimer that is no
> longer able to reclaim enough EPC pages. Find a victim enclave, which
> will be an enclave with only "unreclaimable" EPC pages left
Hi Jo,
Just FYI I won't review the rest patches in this series. One of the reasons is
I am not that familiar with the rest. Jarkko has reviewed anyway :-).
On Thu, 2023-10-05 at 17:38 +0200, Jo Van Bulck wrote:
> Hi,
>
> This patch series ensures that all SGX selftests succeed when compiling
> ---
> arch/x86/Kconfig | 13 +
> arch/x86/kernel/cpu/sgx/Makefile | 1 +
> arch/x86/kernel/cpu/sgx/epc_cgroup.c | 415 +++
> arch/x86/kernel/cpu/sgx/epc_cgroup.h | 59
> arch/x86/kernel/cpu/sgx/main.c | 68 -
>
On Thu, 2023-10-05 at 14:33 -0500, Haitao Huang wrote:
> On Thu, 05 Oct 2023 07:30:46 -0500, Huang, Kai wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > +static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct
> > > sgx_epc_page *epc
> > >
> > > -/*
> > > +/**
> > > + * sgx_reclaim_epc_pages() - Reclaim EPC pages from the consumers
> > > + * @nr_to_scan: Number of EPC pages to scan for reclaim
> > > + * @ignore_age: Reclaim a page even if it is young
> > > + *
> > > * Take a fixed number of pages from
On Wed, 2023-10-04 at 23:22 -0500, Haitao Huang wrote:
> On Wed, 04 Oct 2023 16:13:41 -0500, Huang, Kai wrote:
>
> > On Wed, 2023-10-04 at 10:03 -0500, Haitao Huang wrote:
> > > On Tue, 03 Oct 2023 15:07:42 -0500, Huang, Kai
> > > wrote:
> > >
&g
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> Adjust and expose the top-level reclaim function as
> sgx_reclaim_epc_pages() for use by the upcoming EPC cgroup, which will
> initiate reclaim to enforce the max limit.
>
> Make these adjustments to the
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> +static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct sgx_epc_page
> *epc_page)
> +{
> + return _global_lru;
> +}
> +
> +static inline bool sgx_can_reclaim(void)
> +{
> + return !list_empty(_global_lru.reclaimable);
> +}
> +
On Wed, 2023-10-04 at 10:03 -0500, Haitao Huang wrote:
> On Tue, 03 Oct 2023 15:07:42 -0500, Huang, Kai wrote:
>
> > On Tue, 2023-10-03 at 01:45 -0500, Haitao Huang wrote:
> > > >
> > > > Btw, probably a dumb question:
> > > >
> > > >
On Wed, 2023-10-04 at 10:24 -0500, Haitao Huang wrote:
> On Tue, 03 Oct 2023 15:03:48 -0500, Huang, Kai wrote:
>
> > On Mon, 2023-10-02 at 23:49 -0500, Haitao Huang wrote:
> > > On Wed, 27 Sep 2023 05:28:36 -0500, Huang, Kai
> > > wrote:
> > >
&g
On Tue, 2023-10-03 at 00:15 -0500, Haitao Huang wrote:
> On Thu, 28 Sep 2023 04:41:33 -0500, Huang, Kai wrote:
>
> >
> > > --- a/arch/x86/kernel/cpu/sgx/encl.c
> > > +++ b/arch/x86/kernel/cpu/sgx/encl.c
> > > @@ -746,6 +746,7 @@ void sgx_encl_relea
On Tue, 2023-10-03 at 01:45 -0500, Haitao Huang wrote:
> >
> > Btw, probably a dumb question:
> >
> > Theoretically if you only need to find a victim enclave you don't need
> > to put VA
> > pages to the unreclaimable list, because those VA pages will be freed
> > anyway
> > when enclave is
On Mon, 2023-10-02 at 23:49 -0500, Haitao Huang wrote:
> On Wed, 27 Sep 2023 05:28:36 -0500, Huang, Kai wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > Use the lower 3 bits in the flags field of sgx_epc_page struct to
> > > track EPC state
On Tue, 2023-10-03 at 02:00 -0500, Haitao Huang wrote:
> On Wed, 27 Sep 2023 22:59:12 -0500, Huang, Kai wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > From: Kristen Carlson Accardi
> > >
> > > Add SGX EPC memory, MISC_CG_R
1 - 100 of 159 matches
Mail list logo
