[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a789b1c-4c70-158b-d764-daec141a5816@intel.com>
Date: Fri, 2 Dec 2022 13:35:58 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Kristen Carlson Accardi <kristen@...ux.intel.com>,
jarkko@...nel.org, dave.hansen@...ux.intel.com, tj@...nel.org,
linux-kernel@...r.kernel.org, linux-sgx@...r.kernel.org,
cgroups@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Cc: zhiquan1.li@...el.com, Sean Christopherson <seanjc@...gle.com>
Subject: Re: [PATCH v2 02/18] x86/sgx: Store struct sgx_encl when allocating
new VA pages
On 12/2/22 10:36, Kristen Carlson Accardi wrote:
> When allocating new Version Array (VA) pages, pass the struct sgx_encl
> of the enclave that is allocating the page. sgx_alloc_epc_page() will
> store this value in the encl_owner field of the struct sgx_epc_page. In
> a later patch, VA pages will be placed in an unreclaimable queue,
> and then when the cgroup max limit is reached and there are no more
> reclaimable pages and the enclave must be oom killed, all the
> VA pages associated with that enclave can be uncharged and freed.
What does this have to do with the 'encl' that is being passed, though?
In other words, why is this new sgx_epc_page-to-encl mapping needed for
VA pages now, but it wasn't before?
Powered by blists - more mailing lists