From: "Huang, Kai" <kai.huang@intel.com> To: "Christopherson, Sean J" <sean.j.christopherson@intel.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, "platform-driver-x86@vger.kernel.org" <platform-driver-x86@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "nhorman@redhat.com" <nhorman@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "suresh.b.siddha@intel.com" <suresh.b.siddha@intel.com>, "Ayoun, Serge" <serge.ayoun@intel.com>, "hpa@zytor.com" <hpa@zytor.com>, "npmccallum@redhat.com" <npmccallum@redhat.com>, "mingo@redhat.com" <mingo@redhat.com>, "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>, "Hansen, Dave" <dave.hansen@intel.com> Subject: RE: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves Date: Wed, 29 Aug 2018 20:58:09 +0000 [thread overview] Message-ID: <105F7BF4D0229846AF094488D65A09893541195D@PGSMSX112.gar.corp.intel.com> (raw) In-Reply-To: <20180829203351.GB7142@linux.intel.com> > -----Original Message----- > From: Christopherson, Sean J > Sent: Thursday, August 30, 2018 8:34 AM > To: Huang, Kai <kai.huang@intel.com> > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; platform-driver- > x86@vger.kernel.org; x86@kernel.org; nhorman@redhat.com; linux- > kernel@vger.kernel.org; tglx@linutronix.de; suresh.b.siddha@intel.com; Ayoun, > Serge <serge.ayoun@intel.com>; hpa@zytor.com; npmccallum@redhat.com; > mingo@redhat.com; linux-sgx@vger.kernel.org; Hansen, Dave > <dave.hansen@intel.com> > Subject: Re: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves > > On Wed, Aug 29, 2018 at 12:33:54AM -0700, Huang, Kai wrote: > > [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; static u64 > > > > > +sgx_pm_cnt; > > > > > + > > > > > +/* The cache for the last known values of IA32_SGXLEPUBKEYHASHx > > > > > +MSRs > > > > > for each > > > > > + * CPU. The entries are initialized when they are first used by > > > > > sgx_einit(). > > > > > + */ > > > > > +struct sgx_lepubkeyhash { > > > > > + u64 msrs[4]; > > > > > + u64 pm_cnt; > > > > > > > > May I ask why do we need pm_cnt here? In fact why do we need > > > > suspend staff (namely, sgx_pm_cnt above, and related code in this > > > > patch) here in this patch? From the patch commit message I don't > > > > see why we need PM staff here. Please give comment why you need PM > > > > staff, or you may consider to split the PM staff to another patch. > > > > > > Refining the commit message probably makes more sense because > > > without PM code sgx_einit() would be broken. The MSRs have been reset > after waking up. > > > > > > 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. > > > > You mean reset to Intel default? I think we can also just reset the > > cached MSR values on each power cycle, which would be simpler, IMHO? > > Refresh my brain, does hardware reset the MSRs on a transition to S3 or lower? > > > I think we definitely need some code to handle S3-S5, but should be in > > separate patches, since I think the major impact of S3-S5 is entire > > EPC being destroyed. I think keeping pm_cnt is not sufficient enough > > to handle such case? > > > > > > This brings up one question though: how do we deal with VM host going to > sleep? > > > VM guest would not be aware of this. > > > > IMO VM just gets "sudden loss of EPC" after suspend & resume in host. > > SGX driver and SDK should be able to handle "sudden loss of EPC", ie, > > co-working together to re-establish the missing enclaves. > > > > Actually supporting "sudden loss of EPC" is a requirement to support > > live migration of VM w/ SGX. Internally long time ago we had a > > discussion and the decision was we should support SGX live migration given > two facts: > > > > 1) losing platform-dependent is not important. For example, losing > > sealing key is not a problem, as we could get secrets provisioned > > again from remote. 2) Both windows & linux driver commit to support "sudden > loss of EPC". > > > > I don't think we have to support in very first upstream driver, but I > > think we need to support someday. > > Actually, we can easily support this in the driver, at least for SGX1 hardware. That's my guess too. Just want to check whether we are still on the same page :) > SGX2 isn't difficult to handle, but we've intentionally postponed those patches > until SGX1 support is in mainline[1]. > Accesses to the EPC after it is lost will cause faults. Userspace EPC accesses, e.g. > ERESUME, will get a SIGSEGV that the process should interpret as an "I should > restart my enclave" event. The SDK already does this. In the driver, we just need > to be aware of this potential behavior and not freak out. Specifically, SGX_INVD > needs to not WARN on faults that may have been due to a the EPC being nuked. > I think we can even remove the sgx_encl_pm_notifier() code altogether. Possibly we still need to do some cleanup, ie, all structures of enclaves, upon resume? Anyway I am just guessing. Thanks, -Kai > > [1] SGX1 hardware signals a #GP on an access to an invalid EPC page. > SGX2 signals a #PF with the PF_SGX error code bit set. This is > problematic because the kernel looks at the PTEs for CR2 and sees > nothing wrong, so it thinks it should just restart the > instruction, leading to an infinite fault loop. Resolving this > is fairly straightforward, but a complete fix requires propagating > PF_SGX down to the ENCLS fixup handler, which means plumbing the > error code through the fixup handlers or smushing PF_SGX into > trapnr. Since there is a parallel effort to plumb the error code > through the handlers, https://lkml.org/lkml/2018/8/6/924, we opted > to do this in a separate series. > > > Sean, > > > > Would you be able to comment here? > > > > > > > > I think the best measure would be to add a new parameter to > > > sgx_einit() that enforces update of the MSRs. The driver can then > > > set this parameter in the case when sgx_einit() returns > > > SGX_INVALID_LICENSE. This is coherent because the driver requires > > > writable MSRs. It would not be coherent to do it directly in the core because > KVM does not require writable MSRs. > > > > IMHO this is not required, as I mentioned above. > > > > And > > [snip...] > > > > Thanks, > > -Kai
WARNING: multiple messages have this Message-ID (diff)
From: "Huang, Kai" <kai.huang@intel.com> To: "Christopherson, Sean J" <sean.j.christopherson@intel.com> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, "platform-driver-x86@vger.kernel.org" <platform-driver-x86@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>, "nhorman@redhat.com" <nhorman@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "suresh.b.siddha@intel.com" <suresh.b.siddha@intel.com>, "Ayoun, Serge" <serge.ayoun@intel.com>, "hpa@zytor.com" <hpa@zytor.com>, "npmccallum@redhat.com" <npmccallum@redhat.com>, "mingo@redhat.com" <mingo@redhat.com>, "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>, "Hansen, Dave" <dave.hansen@intel.com> Subject: RE: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves Date: Wed, 29 Aug 2018 13:58:09 -0700 [thread overview] Message-ID: <105F7BF4D0229846AF094488D65A09893541195D@PGSMSX112.gar.corp.intel.com> (raw) In-Reply-To: <20180829203351.GB7142@linux.intel.com> > -----Original Message----- > From: Christopherson, Sean J > Sent: Thursday, August 30, 2018 8:34 AM > To: Huang, Kai <kai.huang@intel.com> > Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; platform-driver- > x86@vger.kernel.org; x86@kernel.org; nhorman@redhat.com; linux- > kernel@vger.kernel.org; tglx@linutronix.de; suresh.b.siddha@intel.com; Ayoun, > Serge <serge.ayoun@intel.com>; hpa@zytor.com; npmccallum@redhat.com; > mingo@redhat.com; linux-sgx@vger.kernel.org; Hansen, Dave > <dave.hansen@intel.com> > Subject: Re: [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves > > On Wed, Aug 29, 2018 at 12:33:54AM -0700, Huang, Kai wrote: > > [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; static u64 > > > > > +sgx_pm_cnt; > > > > > + > > > > > +/* The cache for the last known values of IA32_SGXLEPUBKEYHASHx > > > > > +MSRs > > > > > for each > > > > > + * CPU. The entries are initialized when they are first used by > > > > > sgx_einit(). > > > > > + */ > > > > > +struct sgx_lepubkeyhash { > > > > > + u64 msrs[4]; > > > > > + u64 pm_cnt; > > > > > > > > May I ask why do we need pm_cnt here? In fact why do we need > > > > suspend staff (namely, sgx_pm_cnt above, and related code in this > > > > patch) here in this patch? From the patch commit message I don't > > > > see why we need PM staff here. Please give comment why you need PM > > > > staff, or you may consider to split the PM staff to another patch. > > > > > > Refining the commit message probably makes more sense because > > > without PM code sgx_einit() would be broken. The MSRs have been reset > after waking up. > > > > > > 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. > > > > You mean reset to Intel default? I think we can also just reset the > > cached MSR values on each power cycle, which would be simpler, IMHO? > > Refresh my brain, does hardware reset the MSRs on a transition to S3 or lower? > > > I think we definitely need some code to handle S3-S5, but should be in > > separate patches, since I think the major impact of S3-S5 is entire > > EPC being destroyed. I think keeping pm_cnt is not sufficient enough > > to handle such case? > > > > > > This brings up one question though: how do we deal with VM host going to > sleep? > > > VM guest would not be aware of this. > > > > IMO VM just gets "sudden loss of EPC" after suspend & resume in host. > > SGX driver and SDK should be able to handle "sudden loss of EPC", ie, > > co-working together to re-establish the missing enclaves. > > > > Actually supporting "sudden loss of EPC" is a requirement to support > > live migration of VM w/ SGX. Internally long time ago we had a > > discussion and the decision was we should support SGX live migration given > two facts: > > > > 1) losing platform-dependent is not important. For example, losing > > sealing key is not a problem, as we could get secrets provisioned > > again from remote. 2) Both windows & linux driver commit to support "sudden > loss of EPC". > > > > I don't think we have to support in very first upstream driver, but I > > think we need to support someday. > > Actually, we can easily support this in the driver, at least for SGX1 hardware. That's my guess too. Just want to check whether we are still on the same page :) > SGX2 isn't difficult to handle, but we've intentionally postponed those patches > until SGX1 support is in mainline[1]. > Accesses to the EPC after it is lost will cause faults. Userspace EPC accesses, e.g. > ERESUME, will get a SIGSEGV that the process should interpret as an "I should > restart my enclave" event. The SDK already does this. In the driver, we just need > to be aware of this potential behavior and not freak out. Specifically, SGX_INVD > needs to not WARN on faults that may have been due to a the EPC being nuked. > I think we can even remove the sgx_encl_pm_notifier() code altogether. Possibly we still need to do some cleanup, ie, all structures of enclaves, upon resume? Anyway I am just guessing. Thanks, -Kai > > [1] SGX1 hardware signals a #GP on an access to an invalid EPC page. > SGX2 signals a #PF with the PF_SGX error code bit set. This is > problematic because the kernel looks at the PTEs for CR2 and sees > nothing wrong, so it thinks it should just restart the > instruction, leading to an infinite fault loop. Resolving this > is fairly straightforward, but a complete fix requires propagating > PF_SGX down to the ENCLS fixup handler, which means plumbing the > error code through the fixup handlers or smushing PF_SGX into > trapnr. Since there is a parallel effort to plumb the error code > through the handlers, https://lkml.org/lkml/2018/8/6/924, we opted > to do this in a separate series. > > > Sean, > > > > Would you be able to comment here? > > > > > > > > I think the best measure would be to add a new parameter to > > > sgx_einit() that enforces update of the MSRs. The driver can then > > > set this parameter in the case when sgx_einit() returns > > > SGX_INVALID_LICENSE. This is coherent because the driver requires > > > writable MSRs. It would not be coherent to do it directly in the core because > KVM does not require writable MSRs. > > > > IMHO this is not required, as I mentioned above. > > > > And > > [snip...] > > > > Thanks, > > -Kai
next prev parent reply other threads:[~2018-08-29 20:58 UTC|newest] Thread overview: 259+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-27 18:53 [PATCH v13 00/13] Intel SGX1 support Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 01/13] x86/sgx: Update MAINTAINERS Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-09-03 12:56 ` Andy Shevchenko 2018-09-03 12:56 ` Andy Shevchenko 2018-09-03 19:10 ` Jarkko Sakkinen 2018-09-03 19:10 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 02/13] x86/cpufeature: Add SGX and SGX_LC CPU features Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-28 0:07 ` Huang, Kai 2018-08-28 0:07 ` Huang, Kai 2018-08-28 0:07 ` Huang, Kai 2018-08-28 7:17 ` Jarkko Sakkinen 2018-08-28 7:17 ` Jarkko Sakkinen 2018-08-29 7:36 ` Huang, Kai 2018-08-29 7:36 ` Huang, Kai 2018-08-29 7:36 ` Huang, Kai 2018-08-31 12:19 ` Jarkko Sakkinen 2018-08-31 12:19 ` Jarkko Sakkinen 2018-08-31 12:19 ` Jarkko Sakkinen 2018-08-31 16:18 ` Dr. Greg 2018-08-31 16:18 ` Dr. Greg 2018-08-31 16:18 ` Dr. Greg 2018-08-27 18:53 ` [PATCH v13 03/13] x86/cpufeatures: Add Intel-defined SGX leaf CPUID_12_EAX Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 19:39 ` Dave Hansen 2018-08-27 19:39 ` Dave Hansen 2018-08-27 19:39 ` Dave Hansen 2018-08-27 19:39 ` Dave Hansen 2018-08-28 7:23 ` Jarkko Sakkinen 2018-08-28 7:23 ` Jarkko Sakkinen 2018-08-28 10:21 ` Borislav Petkov 2018-08-28 10:21 ` Borislav Petkov 2018-08-28 10:38 ` Jarkko Sakkinen 2018-08-28 10:38 ` Jarkko Sakkinen 2018-08-28 10:38 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 04/13] x86/sgx: Architectural structures Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 19:41 ` Dave Hansen 2018-08-27 19:41 ` Dave Hansen 2018-08-27 19:41 ` Dave Hansen 2018-08-28 8:08 ` Jarkko Sakkinen 2018-08-28 8:08 ` Jarkko Sakkinen 2018-08-28 8:08 ` Jarkko Sakkinen 2018-09-03 13:16 ` Andy Shevchenko 2018-09-03 13:16 ` Andy Shevchenko 2018-09-03 19:17 ` Jarkko Sakkinen 2018-09-03 19:17 ` Jarkko Sakkinen 2018-09-04 16:04 ` Dave Hansen 2018-09-04 16:04 ` Dave Hansen 2018-09-04 16:06 ` Andy Shevchenko 2018-09-04 16:06 ` Andy Shevchenko 2018-09-05 17:32 ` Jarkko Sakkinen 2018-09-05 17:32 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 05/13] x86/msr: Add SGX definitions to msr-index.h Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 19:42 ` Dave Hansen 2018-08-27 19:42 ` Dave Hansen 2018-08-27 19:42 ` Dave Hansen 2018-08-28 8:11 ` Jarkko Sakkinen 2018-08-28 8:11 ` Jarkko Sakkinen 2018-08-28 8:11 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 06/13] x86/sgx: Detect Intel SGX Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 19:53 ` Dave Hansen 2018-08-27 19:53 ` Dave Hansen 2018-08-27 19:53 ` Dave Hansen 2018-08-28 8:28 ` Jarkko Sakkinen 2018-08-28 8:28 ` Jarkko Sakkinen 2018-08-28 8:28 ` Jarkko Sakkinen 2018-09-03 14:26 ` Andy Shevchenko 2018-09-03 14:26 ` Andy Shevchenko 2018-09-04 9:56 ` Jarkko Sakkinen 2018-09-04 9:56 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 21:07 ` Dave Hansen 2018-08-27 21:07 ` Dave Hansen 2018-08-27 21:07 ` Dave Hansen 2018-08-28 10:30 ` Jarkko Sakkinen 2018-08-28 10:30 ` Jarkko Sakkinen 2018-08-28 10:30 ` Jarkko Sakkinen 2018-08-28 16:53 ` Dave Hansen 2018-08-28 16:53 ` Dave Hansen 2018-08-28 16:53 ` Dave Hansen 2018-08-28 21:34 ` Sean Christopherson 2018-08-28 21:34 ` Sean Christopherson 2018-08-28 21:34 ` Sean Christopherson 2018-08-31 11:13 ` Jarkko Sakkinen 2018-08-31 11:13 ` Jarkko Sakkinen 2018-08-31 11:13 ` Jarkko Sakkinen 2018-08-31 11:10 ` Jarkko Sakkinen 2018-08-31 11:10 ` Jarkko Sakkinen 2018-08-31 11:10 ` Jarkko Sakkinen 2018-09-03 14:41 ` Andy Shevchenko 2018-09-03 14:41 ` Andy Shevchenko 2018-09-04 9:59 ` Jarkko Sakkinen 2018-09-04 9:59 ` Jarkko Sakkinen 2018-09-04 17:49 ` Sean Christopherson 2018-09-04 17:49 ` Sean Christopherson 2018-09-04 18:01 ` Andy Shevchenko 2018-09-04 18:01 ` Andy Shevchenko 2018-09-04 18:17 ` Sean Christopherson 2018-09-04 18:17 ` Sean Christopherson 2018-09-05 17:36 ` Jarkko Sakkinen 2018-09-05 17:36 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 08/13] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-09-03 15:01 ` Andy Shevchenko 2018-09-03 15:01 ` Andy Shevchenko 2018-09-04 11:09 ` Jarkko Sakkinen 2018-09-04 11:09 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 09/13] x86/sgx: Enclave Page Cache (EPC) memory manager Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 21:14 ` Dave Hansen 2018-08-27 21:14 ` Dave Hansen 2018-08-27 21:14 ` Dave Hansen 2018-08-28 8:36 ` Jarkko Sakkinen 2018-08-28 8:36 ` Jarkko Sakkinen 2018-08-28 8:36 ` Jarkko Sakkinen 2018-08-27 21:15 ` Dave Hansen 2018-08-27 21:15 ` Dave Hansen 2018-08-27 21:15 ` Dave Hansen 2018-08-28 8:35 ` Jarkko Sakkinen 2018-08-28 8:35 ` Jarkko Sakkinen 2018-08-28 8:35 ` Jarkko Sakkinen 2018-08-28 14:07 ` Dave Hansen 2018-08-28 14:07 ` Dave Hansen 2018-08-28 14:07 ` Dave Hansen 2018-08-28 21:22 ` Sean Christopherson 2018-08-28 21:22 ` Sean Christopherson 2018-08-28 21:22 ` Sean Christopherson 2018-08-28 21:26 ` Dave Hansen 2018-08-28 21:26 ` Dave Hansen 2018-08-28 21:26 ` Dave Hansen 2018-08-28 21:52 ` Sean Christopherson 2018-08-28 21:52 ` Sean Christopherson 2018-08-28 21:52 ` Sean Christopherson 2018-08-31 11:22 ` Jarkko Sakkinen 2018-08-31 11:22 ` Jarkko Sakkinen 2018-08-31 11:22 ` Jarkko Sakkinen 2018-09-03 19:02 ` Andy Shevchenko 2018-09-03 19:02 ` Andy Shevchenko 2018-09-04 15:38 ` Jarkko Sakkinen 2018-09-04 15:38 ` Jarkko Sakkinen 2018-09-04 15:45 ` Sean Christopherson 2018-09-04 15:45 ` Sean Christopherson 2018-09-11 15:04 ` Sean Christopherson 2018-09-11 15:04 ` Sean Christopherson 2018-09-11 15:04 ` Sean Christopherson 2018-09-16 11:40 ` Jarkko Sakkinen 2018-09-16 11:40 ` Jarkko Sakkinen 2018-09-16 11:40 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 10/13] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 21:41 ` Huang, Kai 2018-08-27 21:41 ` Huang, Kai 2018-08-27 21:41 ` Huang, Kai 2018-08-28 7:01 ` Jarkko Sakkinen 2018-08-28 7:01 ` Jarkko Sakkinen 2018-08-29 7:33 ` Huang, Kai 2018-08-29 7:33 ` Huang, Kai 2018-08-29 7:33 ` Huang, Kai 2018-08-29 20:33 ` Sean Christopherson 2018-08-29 20:33 ` Sean Christopherson 2018-08-29 20:58 ` Huang, Kai [this message] 2018-08-29 20:58 ` Huang, Kai 2018-08-29 20:58 ` Huang, Kai 2018-08-29 21:09 ` Sean Christopherson 2018-08-29 21:09 ` Sean Christopherson 2018-08-30 1:45 ` Huang, Kai 2018-08-30 1:45 ` Huang, Kai 2018-08-30 1:45 ` Huang, Kai 2018-08-31 17:43 ` Sean Christopherson 2018-08-31 17:43 ` Sean Christopherson 2018-08-31 21:34 ` Dr. Greg 2018-08-31 21:34 ` Dr. Greg 2018-08-31 21:34 ` Dr. Greg 2018-09-03 19:27 ` Jarkko Sakkinen 2018-09-03 19:27 ` Jarkko Sakkinen 2018-09-03 18:15 ` Jarkko Sakkinen 2018-09-03 18:15 ` Jarkko Sakkinen 2018-08-31 12:17 ` Jarkko Sakkinen 2018-08-31 12:17 ` Jarkko Sakkinen 2018-08-31 18:15 ` Sean Christopherson 2018-08-31 18:15 ` Sean Christopherson 2018-09-03 19:19 ` Jarkko Sakkinen 2018-09-03 19:19 ` Jarkko Sakkinen 2018-09-03 23:45 ` Huang, Kai 2018-09-03 23:45 ` Huang, Kai 2018-09-03 23:45 ` Huang, Kai 2018-09-04 14:54 ` Sean Christopherson 2018-09-04 14:54 ` Sean Christopherson 2018-09-04 15:30 ` Jarkko Sakkinen 2018-09-04 15:30 ` Jarkko Sakkinen 2018-09-04 16:35 ` Sean Christopherson 2018-09-04 16:35 ` Sean Christopherson 2018-09-04 22:13 ` Huang, Kai 2018-09-04 22:13 ` Huang, Kai 2018-09-04 22:13 ` Huang, Kai 2018-09-05 17:39 ` Jarkko Sakkinen 2018-09-05 17:39 ` Jarkko Sakkinen 2018-09-04 15:26 ` Jarkko Sakkinen 2018-09-04 15:26 ` Jarkko Sakkinen 2018-09-03 13:53 ` Jann Horn 2018-09-03 13:53 ` Jann Horn 2018-09-04 9:55 ` Jarkko Sakkinen 2018-09-04 9:55 ` Jarkko Sakkinen 2018-09-04 16:05 ` Andy Shevchenko 2018-09-04 16:05 ` Andy Shevchenko 2018-08-27 18:53 ` [PATCH v13 11/13] platform/x86: Intel SGX driver Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-09-04 17:59 ` Andy Shevchenko 2018-09-04 17:59 ` Andy Shevchenko 2018-09-05 17:33 ` Jarkko Sakkinen 2018-09-05 17:33 ` Jarkko Sakkinen 2018-09-05 17:36 ` Andy Shevchenko 2018-09-05 17:36 ` Andy Shevchenko 2018-09-06 9:21 ` Jarkko Sakkinen 2018-09-06 9:21 ` Jarkko Sakkinen 2018-09-06 17:35 ` Miguel Ojeda 2018-09-06 17:35 ` Miguel Ojeda 2018-09-07 0:50 ` Joe Perches 2018-09-07 0:50 ` Joe Perches 2018-09-07 17:02 ` Sean Christopherson 2018-09-07 17:02 ` Sean Christopherson 2018-09-07 17:02 ` Sean Christopherson 2018-09-10 18:37 ` Jarkko Sakkinen 2018-09-10 18:37 ` Jarkko Sakkinen 2018-09-10 21:22 ` Joe Perches 2018-09-10 21:22 ` Joe Perches 2018-09-10 18:33 ` Jarkko Sakkinen 2018-09-10 18:33 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 12/13] platform/x86: ptrace() support for the " Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` [PATCH v13 13/13] x86/sgx: Driver documentation Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 18:53 ` Jarkko Sakkinen 2018-08-27 19:40 ` Randy Dunlap 2018-08-27 19:40 ` Randy Dunlap 2018-08-28 7:58 ` Jarkko Sakkinen 2018-08-28 7:58 ` Jarkko Sakkinen 2018-08-28 8:03 ` Jarkko Sakkinen 2018-08-28 8:03 ` Jarkko Sakkinen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=105F7BF4D0229846AF094488D65A09893541195D@PGSMSX112.gar.corp.intel.com \ --to=kai.huang@intel.com \ --cc=dave.hansen@intel.com \ --cc=hpa@zytor.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sgx@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=nhorman@redhat.com \ --cc=npmccallum@redhat.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=sean.j.christopherson@intel.com \ --cc=serge.ayoun@intel.com \ --cc=suresh.b.siddha@intel.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.