> > >
> > > -/*
> > > +/**
> > > + * 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
On Fri, 2023-09-29 at 10:06 -0500, Haitao Huang wrote:
> On Wed, 27 Sep 2023 16:21:19 -0500, Huang, Kai wrote:
>
> > On Wed, 2023-09-27 at 10:35 -0500, Haitao Huang wrote:
> > > > > +
> > > > > + /* Possible owner types */
> > > > > +
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -746,6 +746,7 @@ void sgx_encl_release(struct kref *ref)
> xa_destroy(>page_array);
>
> if (!encl->secs_child_cnt && encl->secs.epc_page) {
> + sgx_drop_epc_page(encl->secs.epc_page);
>
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> @@ -314,18 +313,22 @@ static void sgx_reclaim_pages(void)
>
> if (kref_get_unless_zero(_page->encl->refcount) != 0) {
> sgx_epc_page_set_state(epc_page,
> SGX_EPC_PAGE_RECLAIM_IN_PROGRESS);
> -
On Fri, 2023-09-22 at 20:06 -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.
>
> Add per resource type private data so that SGX can store additional per
> cgroup data in
On Wed, 2023-09-27 at 10:35 -0500, Haitao Huang wrote:
> > > +
> > > + /* Possible owner types */
> > > + union {
> > > + struct sgx_encl_page *encl_page;
> > > + struct sgx_encl *encl;
> > > + };
> >
> > Sadly for virtual EPC page the owner is set to the 'sgx_vepc' instance it
>
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> When an OOM event occurs, all pages associated with an enclave will need
> to be freed, including pages that are not currently tracked by the
> cgroup LRU lists.
What are "cgroup LRU lists"?
>
> Add a new
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> In a later patch, when a cgroup has exceeded the max capacity for EPC
> pages, it may need to identify and OOM kill a less active enclave to
> make room for other enclaves within the same group. Such a victim
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> In a later patch, when a cgroup has exceeded the max capacity for EPC
> pages, it may need to identify and OOM kill a less active enclave to
> make room for other enclaves within the same group. Such a victim
> @@ -312,13 +312,15 @@ static void sgx_reclaim_pages(void)
> list_del_init(_page->list);
> encl_page = epc_page->owner;
>
> - if (kref_get_unless_zero(_page->encl->refcount) != 0)
> + if (kref_get_unless_zero(_page->encl->refcount) != 0) {
>
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 states in its life cycle and define an enum for possible
> states. More state(s) will be added later.
This patch does more than what the changelog claims to do.
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -268,7 +268,6 @@ static void sgx_reclaimer_write(struct sgx_epc_page
> *epc_page,
> goto out;
>
>
On Fri, 2023-09-22 at 20:06 -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 Thu, 2023-09-14 at 09:13 -0700, Dave Hansen wrote:
> On 9/14/23 03:31, Huang, Kai wrote:
> > > Signed-off-by: Haitao Huang
> > > Cc: Sean Christopherson
> > You don't need 'Cc:' Sean if the patch has Sean's SoB.
>
> It is a SoB for Sean's @intel add
Some non-technical staff:
On Tue, 2023-09-12 at 21:06 -0700, Haitao Huang wrote:
> From: Kristen Carlson Accardi
The patch was from Kristen, but ...
>
> Introduce a data structure to wrap the existing reclaimable list and its
> spinlock. Each cgroup later will have one instance of this
> On Fri, Mar 19, 2021 at 08:29:27PM +1300, Kai Huang wrote:
> > This series adds KVM SGX virtualization support. The first 14 patches
> > starting with x86/sgx or x86/cpu.. are necessary changes to x86 and
> > SGX core/driver to support KVM SGX virtualization, while the rest are
> > patches
> to
On Wed, 2020-05-27 at 10:39 +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
> > On Mon, May 25, 2020 at 06:15:25PM +0300, Kirill A. Shutemov wrote:
> > > On Mon, May 25, 2020 at 04:58:51PM +0200, Vitaly Kuznetsov wrote:
> > > > > @@ -727,6 +734,15 @@ static void __init
On Mon, 2020-05-25 at 18:34 +0300, Kirill A. Shutemov wrote:
> On Mon, May 25, 2020 at 05:26:37PM +0200, Vitaly Kuznetsov wrote:
> > "Kirill A. Shutemov" writes:
> >
> > > Add infrastructure that handles protected memory extension.
> > >
> > > Arch-specific code has to provide hypercalls and
On Mon, 2019-06-24 at 17:12 -0700, Song Liu wrote:
> This patch is (hopefully) the first step to enable THP for non-shmem
> filesystems.
>
> This patch enables an application to put part of its text sections to THP
> via madvise, for example:
>
> madvise((void *)0x60, 0x20,
On Mon, 2019-06-17 at 23:01 +1200, Kai Huang wrote:
> On Mon, 2019-06-17 at 11:30 +0200, Peter Zijlstra wrote:
> > On Sat, Jun 15, 2019 at 01:44:43AM +0300, Kirill A. Shutemov wrote:
> > > On Fri, Jun 14, 2019 at 01:12:59PM +0200, Peter Zijlstra wrote:
> > > > On Wed, May 08, 2019 at 05:43:40PM
On Wed, 2019-04-17 at 13:39 +0300, Jarkko Sakkinen wrote:
> In order to provide a mechanism for devilering provisoning rights:
>
> 1. Add a new device file /dev/sgx/provision that works as a token for
>allowing an enclave to have the provisioning privileges.
> 2. Add a new ioctl called
> On Tue, Mar 26, 2019 at 02:25:52PM -0700, Huang, Kai wrote:
> > >
> > > That being said, this in no way impacts KVM's ability to virtualize SGX,
> > > e.g.
> > > KVM can directly do CPUID and {RD,WR}MSR to probe the capabilities
> > > of the pla
>
> On Tue, Mar 26, 2019 at 05:17:40AM -0700, Huang, Kai wrote:
> > On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> > > From: Sean Christopherson
> > >
> > > Similar to other large Intel features such as VMX and TXT, SGX must
> > > b
> On Tue, Mar 26, 2019 at 01:40:57PM +0100, Thomas Gleixner wrote:
> > On Tue, 26 Mar 2019, Huang, Kai wrote:
> > > On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> > > > 13 files changed, 1657 insertions(+), 2 deletions(-) create mode
> > > &
On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Similar to other large Intel features such as VMX and TXT, SGX must be
> explicitly enabled in IA32_FEATURE_CONTROL MSR to be truly usable.
> Clear all SGX related capabilities if SGX is not fully enabled
On Wed, 2019-03-20 at 18:21 +0200, Jarkko Sakkinen wrote:
> Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
> can be used by applications to set aside private regions of code and
> data. The code outside the enclave is disallowed to access the memory
> inside the enclave by
On Thu, 2019-01-10 at 13:34 -0800, Andy Lutomirski wrote:
> > > On Jan 9, 2019, at 8:31 AM, Sean Christopherson
> > > wrote:
> > >
> > > On Tue, Jan 08, 2019 at 02:54:11PM -0800, Andy Lutomirski wrote:
> > > On Tue, Jan 8, 2019 at 2:09 PM Sean Christopherson
> > > wrote:
> > > >
> > > >
> > > That's possible, but it has several downsides.
> > >
> > > - Duplicates a lot of code in KVM for managing memory regions.
> >
> > I don't see why there will be duplicated code. you can simply call
> > __x86_set_memory_region to create private slot. It is KVM x86
> > equivalent to
> On Tue, Jan 08, 2019 at 11:27:11AM -0800, Huang, Kai wrote:
> > > >
> > > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > > > opening a new instance of /dev/sgx for each encalve?
> > >
> > > Directly associating /d
> >
> > Can one of you explain why SGX_ENCLAVE_CREATE is better than just
> > opening a new instance of /dev/sgx for each encalve?
>
> Directly associating /dev/sgx with an enclave means /dev/sgx can't be used
> to provide ioctl()'s for other SGX-related needs, e.g. to mmap() raw EPC and
> expose
> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-x86-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Wednesday, September 5, 2018 4:36 AM
> To: Jarkko Sakkinen
> Cc: Huang, Kai ; platform-driver-...@vg
> -Original Message-
> From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver-x86-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Wednesday, September 5, 2018 4:36 AM
> To: Jarkko Sakkinen
> Cc: Huang, Kai ; platform-driver-...@vg
> -Original Message-
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Jarkko Sakkinen
> Sent: Tuesday, September 4, 2018 7:19 AM
> To: Christopherson, Sean J
> Cc: Huang, Kai ; platform-driver-...@vger.kernel.org;
>
> -Original Message-
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Jarkko Sakkinen
> Sent: Tuesday, September 4, 2018 7:19 AM
> To: Christopherson, Sean J
> Cc: Huang, Kai ; platform-driver-...@vger.kernel.org;
>
> > > > > Some kind of counter is required to keep track of the power cycle.
> > > > > When going to sleep the sgx_pm_cnt is increased. sgx_einit()
> > > > > compares the current value of the global count to the value in
> > > > > the cache entry to see whether we are in a new power cycle.
> > > >
> > > > > Some kind of counter is required to keep track of the power cycle.
> > > > > When going to sleep the sgx_pm_cnt is increased. sgx_einit()
> > > > > compares the current value of the global count to the value in
> > > > > the cache entry to see whether we are in a new power cycle.
> > > >
> -Original Message-
> From: Christopherson, Sean J
> Sent: Thursday, August 30, 2018 8:34 AM
> To: Huang, Kai
> Cc: Jarkko Sakkinen ; platform-driver-
> x...@vger.kernel.org; x...@kernel.org; nhor...@redhat.com; linux-
> ker...@vger.kernel.org; t...@linutr
> -Original Message-
> From: Christopherson, Sean J
> Sent: Thursday, August 30, 2018 8:34 AM
> To: Huang, Kai
> Cc: Jarkko Sakkinen ; platform-driver-
> x...@vger.kernel.org; x...@kernel.org; nhor...@redhat.com; linux-
> ker...@vger.kernel.org; t...@linutr
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, August 28, 2018 7:17 PM
> To: Huang, Kai
> Cc: x...@kernel.org; platform-driver-...@vger.kernel.org; Hansen, Dave
> ; Christopherson, Sean J
> ; nhor...@
> -Original Message-
> From: Jarkko Sakkinen [mailto:jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, August 28, 2018 7:17 PM
> To: Huang, Kai
> Cc: x...@kernel.org; platform-driver-...@vger.kernel.org; Hansen, Dave
> ; Christopherson, Sean J
> ; nhor...@
[snip..]
> > >
> > > @@ -38,6 +39,18 @@ static LIST_HEAD(sgx_active_page_list); static
> > > DEFINE_SPINLOCK(sgx_active_page_list_lock);
> > > static struct task_struct *ksgxswapd_tsk; static
> > > DECLARE_WAIT_QUEUE_HEAD(ksgxswapd_waitq);
> > > +static struct notifier_block sgx_pm_notifier;
[snip..]
> > >
> > > @@ -38,6 +39,18 @@ static LIST_HEAD(sgx_active_page_list); static
> > > DEFINE_SPINLOCK(sgx_active_page_list_lock);
> > > static struct task_struct *ksgxswapd_tsk; static
> > > DECLARE_WAIT_QUEUE_HEAD(ksgxswapd_waitq);
> > > +static struct notifier_block sgx_pm_notifier;
> +#define X86_FEATURE_SGX_LC (16*32+30) /* supports SGX launch
> configuration */
Sorry if it was me who wrote the comment "SGX launch configuration". I think we
should just use "SGX launch control". :)
Thanks,
-Kai
>
> /* AMD-defined CPU features, CPUID level 0x8007 (EBX),
> +#define X86_FEATURE_SGX_LC (16*32+30) /* supports SGX launch
> configuration */
Sorry if it was me who wrote the comment "SGX launch configuration". I think we
should just use "SGX launch control". :)
Thanks,
-Kai
>
> /* AMD-defined CPU features, CPUID level 0x8007 (EBX),
On Mon, 2018-08-27 at 21:53 +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x
>
On Mon, 2018-08-27 at 21:53 +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson
>
> Add a function to perform ENCLS(EINIT), which initializes an enclave,
> which can be used by a driver for running enclaves and VMMs.
>
> Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x
>
On 5/11/2017 3:53 AM, Bandan Das wrote:
Hi Kai,
"Huang, Kai" <kai.hu...@linux.intel.com> writes:
On 5/6/2017 7:25 AM, Bandan Das wrote:
When KVM updates accessed/dirty bits, this hook can be used
to invoke an arch specific function that implements/emulates
dirty log
On 5/11/2017 3:53 AM, Bandan Das wrote:
Hi Kai,
"Huang, Kai" writes:
On 5/6/2017 7:25 AM, Bandan Das wrote:
When KVM updates accessed/dirty bits, this hook can be used
to invoke an arch specific function that implements/emulates
dirty logging such as PML.
Signed-off-by:
On 5/11/2017 4:00 AM, Bandan Das wrote:
Paolo Bonzini writes:
...
Is the purpose of returning 1 to make upper layer code to inject PML
full VMEXIt to L1 in nested_ept_inject_page_fault?
Yes, it triggers a fault
+
+gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) &
On 5/11/2017 4:00 AM, Bandan Das wrote:
Paolo Bonzini writes:
...
Is the purpose of returning 1 to make upper layer code to inject PML
full VMEXIt to L1 in nested_ept_inject_page_fault?
Yes, it triggers a fault
+
+gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) & ~0xFFFull;
+
+
On 5/6/2017 7:25 AM, Bandan Das wrote:
When KVM updates accessed/dirty bits, this hook can be used
to invoke an arch specific function that implements/emulates
dirty logging such as PML.
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_host.h | 2 ++
On 5/6/2017 7:25 AM, Bandan Das wrote:
When KVM updates accessed/dirty bits, this hook can be used
to invoke an arch specific function that implements/emulates
dirty logging such as PML.
Signed-off-by: Bandan Das
---
arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/mmu.c |
On 5/6/2017 7:25 AM, Bandan Das wrote:
With EPT A/D enabled, processor access to L2 guest
paging structures will result in a write violation.
When this happens, write the GUEST_PHYSICAL_ADDRESS
to the pml buffer provided by L1 if the access is
write and the dirty bit is being set.
This patch
On 5/6/2017 7:25 AM, Bandan Das wrote:
With EPT A/D enabled, processor access to L2 guest
paging structures will result in a write violation.
When this happens, write the GUEST_PHYSICAL_ADDRESS
to the pml buffer provided by L1 if the access is
write and the dirty bit is being set.
This patch
Thanks!
Thanks,
-Kai
On 3/14/2017 5:57 AM, Paolo Bonzini wrote:
On 13/03/2017 15:58, fangying wrote:
Hi, Huang Kai
After weeks of intensive testing, we think the problem is solved and
this issue can be closed.
Thanks for the update. We got to the same conclusion.
Paolo
Thanks!
Thanks,
-Kai
On 3/14/2017 5:57 AM, Paolo Bonzini wrote:
On 13/03/2017 15:58, fangying wrote:
Hi, Huang Kai
After weeks of intensive testing, we think the problem is solved and
this issue can be closed.
Thanks for the update. We got to the same conclusion.
Paolo
On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote:
On 2017/2/24 23:14, Paolo Bonzini wrote:
On 24/02/2017 16:10, Chris Friesen wrote:
On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote:
On 2017/2/22 22:43, Paolo Bonzini wrote:
Hopefully Gaohuai and Rongguang can help with this too.
On 2/25/2017 2:44 PM, Herongguang (Stephen) wrote:
On 2017/2/24 23:14, Paolo Bonzini wrote:
On 24/02/2017 16:10, Chris Friesen wrote:
On 02/23/2017 08:23 PM, Herongguang (Stephen) wrote:
On 2017/2/22 22:43, Paolo Bonzini wrote:
Hopefully Gaohuai and Rongguang can help with this too.
On 4/27/2016 10:58 AM, Tom Lendacky wrote:
Add support to set the memory encryption enable flag on the APs during
realmode initialization. When an AP is started it checks this flag, and
if set, enables memory encryption on its core.
Signed-off-by: Tom Lendacky
---
On 4/27/2016 10:58 AM, Tom Lendacky wrote:
Add support to set the memory encryption enable flag on the APs during
realmode initialization. When an AP is started it checks this flag, and
if set, enables memory encryption on its core.
Signed-off-by: Tom Lendacky
---
101 - 169 of 169 matches
Mail list logo