All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: x86@kernel.org, platform-driver-x86@vger.kernel.org,
	sean.j.christopherson@intel.com, nhorman@redhat.com,
	npmccallum@redhat.com, linux-sgx@vger.kernel.org,
	Serge Ayoun <serge.ayoun@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages
Date: Tue, 28 Aug 2018 13:30:40 +0300	[thread overview]
Message-ID: <20180828103040.GA21326@linux.intel.com> (raw)
In-Reply-To: <4666cae8-c711-8dd5-cbce-3d97cc19a9e5@intel.com>

On Mon, Aug 27, 2018 at 02:07:53PM -0700, Dave Hansen wrote:
> On 08/27/2018 11:53 AM, Jarkko Sakkinen wrote:
> > Add data structures to track Enclave Page Cache (EPC) pages.  EPC is
> > divided into multiple banks (1-N) of which addresses and sizes can be
> > enumerated with CPUID by the OS.
> > 
> > On NUMA systems a node can have at most bank. A bank can be at most part of
> > two nodes. SGX supports both nodes with a single memory controller and also
> > sub-cluster nodes with severals memory controllers on a single die.
> > 
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
> > Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > ---
> >  arch/x86/include/asm/sgx.h      |  60 ++++++++++++++++++
> >  arch/x86/kernel/cpu/intel_sgx.c | 106 +++++++++++++++++++++++++++++++-
> >  2 files changed, 164 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
> > index 2130e639ab49..17b7b3aa66bf 100644
> > --- a/arch/x86/include/asm/sgx.h
> > +++ b/arch/x86/include/asm/sgx.h
> > @@ -4,9 +4,69 @@
> >  #ifndef _ASM_X86_SGX_H
> >  #define _ASM_X86_SGX_H
> >  
> > +#include <linux/bitops.h>
> > +#include <linux/err.h>
> > +#include <linux/rwsem.h>
> >  #include <linux/types.h>
> > +#include <asm/sgx_arch.h>
> > +#include <asm/asm.h>
> > +
> > +#define SGX_MAX_EPC_BANKS 8
> 
> This is _still_ missing a meaningful description of what a bank is and
> whether it is a hardware or software structure.
> 
> It would also help us to determine whether your bit packing below is
> really required.

I think a better name would be EPC section as this is what the SDM uses
in the Table 3-8 when describing subleaves of EAX=0x12 (SGX specific
leaf) starting from ECX=0x02. It is a software structure that contains
the information given by these subleaves.

These sections constitute the physical pages that are part of the EPC.

> > +struct sgx_epc_page {
> > +	unsigned long desc;
> > +	struct list_head list;
> > +};
> > +
> > +struct sgx_epc_bank {
> > +	unsigned long pa;
> > +	void *va;
> > +	unsigned long size;
> 
> Please add units.  size could be bytes or pages, or who knows what.  I
> can't tell you how many bugs I've tripped over in the past from simple
> unit conversions

Will do.

> > +	struct sgx_epc_page *pages_data;
> > +	struct sgx_epc_page **pages;
> > +	unsigned long free_cnt;
> > +	spinlock_t lock;
> > +};
> >  
> >  extern bool sgx_enabled;
> >  extern bool sgx_lc_enabled;
> > +extern struct sgx_epc_bank sgx_epc_banks[SGX_MAX_EPC_BANKS];
> > +
> > +/*
> > + * enum sgx_epc_page_desc - defines bits and masks for an EPC page's desc
> 
> Why are you bothering packing these bits?  This seems a rather
> convoluted way to store two integers.

To keep struct sgx_epc_page 64 bytes.

> > +static __init int sgx_init_epc_bank(u64 addr, u64 size, unsigned long index,
> > +				    struct sgx_epc_bank *bank)
> > +{
> > +	unsigned long nr_pages = size >> PAGE_SHIFT;
> > +	struct sgx_epc_page *pages_data;
> > +	unsigned long i;
> > +	void *va;
> > +
> > +	va = ioremap_cache(addr, size);
> > +	if (!va)
> > +		return -ENOMEM;
> > +
> > +	pages_data = kcalloc(nr_pages, sizeof(struct sgx_epc_page), GFP_KERNEL);
> > +	if (!pages_data)
> > +		goto out_iomap;
> 
> This looks like you're roughly limited by the page allocator to a bank
> size of ~1.4GB which seems kinda small.  Is this really OK?

Where does this limitation come from?

> 
> > +	bank->pages = kcalloc(nr_pages, sizeof(struct sgx_epc_page *),
> > +			      GFP_KERNEL);
> > +	if (!bank->pages)
> > +		goto out_pdata;
> > +
> > +	for (i = 0; i < nr_pages; i++) {
> > +		bank->pages[i] = &pages_data[i];
> > +		bank->pages[i]->desc = (addr + (i << PAGE_SHIFT)) | index;
> > +	}
> > +
> > +	bank->pa = addr;
> > +	bank->size = size;
> > +	bank->va = va;
> > +	bank->free_cnt = nr_pages;
> > +	bank->pages_data = pages_data;
> > +	spin_lock_init(&bank->lock);
> > +	return 0;
> > +out_pdata:
> > +	kfree(pages_data);
> > +out_iomap:
> > +	iounmap(va);
> > +	return -ENOMEM;
> > +}
> > +
> > +static __init void sgx_page_cache_teardown(void)
> > +{
> > +	struct sgx_epc_bank *bank;
> > +	int i;
> > +
> > +	for (i = 0; i < sgx_nr_epc_banks; i++) {
> > +		bank = &sgx_epc_banks[i];
> > +		iounmap((void *)bank->va);
> > +		kfree(bank->pages);
> > +		kfree(bank->pages_data);
> > +	}
> > +}
> > +
> > +static inline u64 sgx_combine_bank_regs(u64 low, u64 high)
> > +{
> > +	return (low & 0xFFFFF000) + ((high & 0xFFFFF) << 32);
> > +}
> 
> -ENOCOMMENT for a rather weird looking calculation

Yea, totally agreed... I'll think about how to make this cleaner. Maybe
it would be anyway better idea to open code this to the call sites and
explain the calculation in a comment.

> > +static __init int sgx_page_cache_init(void)
> > +{
> > +	u32 eax, ebx, ecx, edx;
> > +	u64 pa, size;
> > +	int ret;
> > +	int i;
> > +
> > +	for (i = 0; i < SGX_MAX_EPC_BANKS; i++) {
> > +		cpuid_count(SGX_CPUID, 2 + i, &eax, &ebx, &ecx, &edx);
> > +		if (!(eax & 0xF))
> > +			break;
> 
> So, we have random data coming out of a random CPUID leaf being called
> 'eax' and then being tested against a random hard-coded mask.  This
> seems rather unfortunate for someone trying to understand the code.  Can
> we do better?

Should probably do something along the lines:

#define SGX_CPUID_SECTION(i) (2 + (i))

enum sgx_section {
	SGX_CPUID_SECTION_INVALID	= 0x00,
	SGX_CPUID_SECTION_VALID		= 0x1B,
	SGX_CPUID_SECTION_MASK		= 0xFF,
};


for (i = 0; i < SGX_MAX_EPC_BANKS; i++) {
	cpuid_count(SGX_CPUID, SGX_CPUID_SECTION(i), &eax, &ebx, &ecx, &edx);

	section = eax & SGX_SECTION_MASK;
	if (section != SGX_CPUID_SECTION_VALID) {
		if (section != SGX_CPUID_SECTION_INVALID) {
			/* Maybe a warning here for any other value as
			 * they are reserved according to the SDM?
			 */
		}

		continue;
	}

	/* ... */
}

> > +		pa = sgx_combine_bank_regs(eax, ebx);
> > +		size = sgx_combine_bank_regs(ecx, edx);
> > +		pr_info("EPC bank 0x%llx-0x%llx\n", pa, pa + size - 1);
> > +		ret = sgx_init_epc_bank(pa, size, i, &sgx_epc_banks[i]);
> > +		if (ret) {
> > +			sgx_page_cache_teardown();
> > +			return ret;
> > +		}
> 
> So if one bank fails, we tear down all banks, yet leave sgx_nr_epc_banks
> incremented?  That sounds troublesome.

It is. Thanks for spotting that out.

> > +		sgx_nr_epc_banks++;
> > +	}
> > +
> > +	if (!sgx_nr_epc_banks) {
> > +		pr_err("There are zero EPC banks.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	return 0;
> > +}
> 
> Does this support hot-addition of a bank?  If not, why not?

This is the DSDT for this data from my GLK NUC:

    Scope (_SB)
    {
        Device (EPC)
        {
            Name (_HID, EisaId ("INT0E0C"))  // _HID: Hardware ID
            Name (_STR, Unicode ("Enclave Page Cache 1.0"))  // _STR: Description String
            Name (_MLS, Package (0x01)  // _MLS: Multiple Language String
            {
                Package (0x02)
                {
                    "en", 
                    Unicode ("Enclave Page Cache 1.0")
                }
            })
            Name (RBUF, ResourceTemplate ()
            {
                QWordMemory (ResourceConsumer, PosDecode, MinNotFixed, MaxNotFixed, NonCacheable, ReadWrite,
                    0x0000000000000000, // Granularity
                    0x0000000000000000, // Range Minimum
                    0x0000000000000000, // Range Maximum
                    0x0000000000000000, // Translation Offset
                    0x0000000000000001, // Length
                    ,, _Y18, AddressRangeMemory, TypeStatic)
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateQWordField (RBUF, \_SB.EPC._Y18._MIN, EMIN)  // _MIN: Minimum Base Address
                CreateQWordField (RBUF, \_SB.EPC._Y18._MAX, EMAX)  // _MAX: Maximum Base Address
                CreateQWordField (RBUF, \_SB.EPC._Y18._LEN, ELEN)  // _LEN: Length
                EMIN = EMNA /* External reference */
                ELEN = ELNG /* External reference */
                EMAX = ((EMNA + ELNG) - One)
                Return (RBUF) /* \_SB_.EPC_.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((EPCS != Zero))
                {
                    Return (0x0F)
                }

                Return (Zero)
            }
        }
    }

I'm not aware that we would have an ACPI specification for SGX so this
is all I have at the moment (does not show any ACPI event for
hotplugging).

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <x86@kernel.org>, <platform-driver-x86@vger.kernel.org>,
	<sean.j.christopherson@intel.com>, <nhorman@redhat.com>,
	<npmccallum@redhat.com>, <linux-sgx@vger.kernel.org>,
	Serge Ayoun <serge.ayoun@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages
Date: Tue, 28 Aug 2018 13:30:40 +0300	[thread overview]
Message-ID: <20180828103040.GA21326@linux.intel.com> (raw)
In-Reply-To: <4666cae8-c711-8dd5-cbce-3d97cc19a9e5@intel.com>

On Mon, Aug 27, 2018 at 02:07:53PM -0700, Dave Hansen wrote:
> On 08/27/2018 11:53 AM, Jarkko Sakkinen wrote:
> > Add data structures to track Enclave Page Cache (EPC) pages.  EPC is
> > divided into multiple banks (1-N) of which addresses and sizes can be
> > enumerated with CPUID by the OS.
> > 
> > On NUMA systems a node can have at most bank. A bank can be at most part of
> > two nodes. SGX supports both nodes with a single memory controller and also
> > sub-cluster nodes with severals memory controllers on a single die.
> > 
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
> > Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> > ---
> >  arch/x86/include/asm/sgx.h      |  60 ++++++++++++++++++
> >  arch/x86/kernel/cpu/intel_sgx.c | 106 +++++++++++++++++++++++++++++++-
> >  2 files changed, 164 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/sgx.h b/arch/x86/include/asm/sgx.h
> > index 2130e639ab49..17b7b3aa66bf 100644
> > --- a/arch/x86/include/asm/sgx.h
> > +++ b/arch/x86/include/asm/sgx.h
> > @@ -4,9 +4,69 @@
> >  #ifndef _ASM_X86_SGX_H
> >  #define _ASM_X86_SGX_H
> >  
> > +#include <linux/bitops.h>
> > +#include <linux/err.h>
> > +#include <linux/rwsem.h>
> >  #include <linux/types.h>
> > +#include <asm/sgx_arch.h>
> > +#include <asm/asm.h>
> > +
> > +#define SGX_MAX_EPC_BANKS 8
> 
> This is _still_ missing a meaningful description of what a bank is and
> whether it is a hardware or software structure.
> 
> It would also help us to determine whether your bit packing below is
> really required.

I think a better name would be EPC section as this is what the SDM uses
in the Table 3-8 when describing subleaves of EAX=0x12 (SGX specific
leaf) starting from ECX=0x02. It is a software structure that contains
the information given by these subleaves.

These sections constitute the physical pages that are part of the EPC.

> > +struct sgx_epc_page {
> > +	unsigned long desc;
> > +	struct list_head list;
> > +};
> > +
> > +struct sgx_epc_bank {
> > +	unsigned long pa;
> > +	void *va;
> > +	unsigned long size;
> 
> Please add units.  size could be bytes or pages, or who knows what.  I
> can't tell you how many bugs I've tripped over in the past from simple
> unit conversions

Will do.

> > +	struct sgx_epc_page *pages_data;
> > +	struct sgx_epc_page **pages;
> > +	unsigned long free_cnt;
> > +	spinlock_t lock;
> > +};
> >  
> >  extern bool sgx_enabled;
> >  extern bool sgx_lc_enabled;
> > +extern struct sgx_epc_bank sgx_epc_banks[SGX_MAX_EPC_BANKS];
> > +
> > +/*
> > + * enum sgx_epc_page_desc - defines bits and masks for an EPC page's desc
> 
> Why are you bothering packing these bits?  This seems a rather
> convoluted way to store two integers.

To keep struct sgx_epc_page 64 bytes.

> > +static __init int sgx_init_epc_bank(u64 addr, u64 size, unsigned long index,
> > +				    struct sgx_epc_bank *bank)
> > +{
> > +	unsigned long nr_pages = size >> PAGE_SHIFT;
> > +	struct sgx_epc_page *pages_data;
> > +	unsigned long i;
> > +	void *va;
> > +
> > +	va = ioremap_cache(addr, size);
> > +	if (!va)
> > +		return -ENOMEM;
> > +
> > +	pages_data = kcalloc(nr_pages, sizeof(struct sgx_epc_page), GFP_KERNEL);
> > +	if (!pages_data)
> > +		goto out_iomap;
> 
> This looks like you're roughly limited by the page allocator to a bank
> size of ~1.4GB which seems kinda small.  Is this really OK?

Where does this limitation come from?

> 
> > +	bank->pages = kcalloc(nr_pages, sizeof(struct sgx_epc_page *),
> > +			      GFP_KERNEL);
> > +	if (!bank->pages)
> > +		goto out_pdata;
> > +
> > +	for (i = 0; i < nr_pages; i++) {
> > +		bank->pages[i] = &pages_data[i];
> > +		bank->pages[i]->desc = (addr + (i << PAGE_SHIFT)) | index;
> > +	}
> > +
> > +	bank->pa = addr;
> > +	bank->size = size;
> > +	bank->va = va;
> > +	bank->free_cnt = nr_pages;
> > +	bank->pages_data = pages_data;
> > +	spin_lock_init(&bank->lock);
> > +	return 0;
> > +out_pdata:
> > +	kfree(pages_data);
> > +out_iomap:
> > +	iounmap(va);
> > +	return -ENOMEM;
> > +}
> > +
> > +static __init void sgx_page_cache_teardown(void)
> > +{
> > +	struct sgx_epc_bank *bank;
> > +	int i;
> > +
> > +	for (i = 0; i < sgx_nr_epc_banks; i++) {
> > +		bank = &sgx_epc_banks[i];
> > +		iounmap((void *)bank->va);
> > +		kfree(bank->pages);
> > +		kfree(bank->pages_data);
> > +	}
> > +}
> > +
> > +static inline u64 sgx_combine_bank_regs(u64 low, u64 high)
> > +{
> > +	return (low & 0xFFFFF000) + ((high & 0xFFFFF) << 32);
> > +}
> 
> -ENOCOMMENT for a rather weird looking calculation

Yea, totally agreed... I'll think about how to make this cleaner. Maybe
it would be anyway better idea to open code this to the call sites and
explain the calculation in a comment.

> > +static __init int sgx_page_cache_init(void)
> > +{
> > +	u32 eax, ebx, ecx, edx;
> > +	u64 pa, size;
> > +	int ret;
> > +	int i;
> > +
> > +	for (i = 0; i < SGX_MAX_EPC_BANKS; i++) {
> > +		cpuid_count(SGX_CPUID, 2 + i, &eax, &ebx, &ecx, &edx);
> > +		if (!(eax & 0xF))
> > +			break;
> 
> So, we have random data coming out of a random CPUID leaf being called
> 'eax' and then being tested against a random hard-coded mask.  This
> seems rather unfortunate for someone trying to understand the code.  Can
> we do better?

Should probably do something along the lines:

#define SGX_CPUID_SECTION(i) (2 + (i))

enum sgx_section {
	SGX_CPUID_SECTION_INVALID	= 0x00,
	SGX_CPUID_SECTION_VALID		= 0x1B,
	SGX_CPUID_SECTION_MASK		= 0xFF,
};


for (i = 0; i < SGX_MAX_EPC_BANKS; i++) {
	cpuid_count(SGX_CPUID, SGX_CPUID_SECTION(i), &eax, &ebx, &ecx, &edx);

	section = eax & SGX_SECTION_MASK;
	if (section != SGX_CPUID_SECTION_VALID) {
		if (section != SGX_CPUID_SECTION_INVALID) {
			/* Maybe a warning here for any other value as
			 * they are reserved according to the SDM?
			 */
		}

		continue;
	}

	/* ... */
}

> > +		pa = sgx_combine_bank_regs(eax, ebx);
> > +		size = sgx_combine_bank_regs(ecx, edx);
> > +		pr_info("EPC bank 0x%llx-0x%llx\n", pa, pa + size - 1);
> > +		ret = sgx_init_epc_bank(pa, size, i, &sgx_epc_banks[i]);
> > +		if (ret) {
> > +			sgx_page_cache_teardown();
> > +			return ret;
> > +		}
> 
> So if one bank fails, we tear down all banks, yet leave sgx_nr_epc_banks
> incremented?  That sounds troublesome.

It is. Thanks for spotting that out.

> > +		sgx_nr_epc_banks++;
> > +	}
> > +
> > +	if (!sgx_nr_epc_banks) {
> > +		pr_err("There are zero EPC banks.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	return 0;
> > +}
> 
> Does this support hot-addition of a bank?  If not, why not?

This is the DSDT for this data from my GLK NUC:

    Scope (_SB)
    {
        Device (EPC)
        {
            Name (_HID, EisaId ("INT0E0C"))  // _HID: Hardware ID
            Name (_STR, Unicode ("Enclave Page Cache 1.0"))  // _STR: Description String
            Name (_MLS, Package (0x01)  // _MLS: Multiple Language String
            {
                Package (0x02)
                {
                    "en", 
                    Unicode ("Enclave Page Cache 1.0")
                }
            })
            Name (RBUF, ResourceTemplate ()
            {
                QWordMemory (ResourceConsumer, PosDecode, MinNotFixed, MaxNotFixed, NonCacheable, ReadWrite,
                    0x0000000000000000, // Granularity
                    0x0000000000000000, // Range Minimum
                    0x0000000000000000, // Range Maximum
                    0x0000000000000000, // Translation Offset
                    0x0000000000000001, // Length
                    ,, _Y18, AddressRangeMemory, TypeStatic)
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                CreateQWordField (RBUF, \_SB.EPC._Y18._MIN, EMIN)  // _MIN: Minimum Base Address
                CreateQWordField (RBUF, \_SB.EPC._Y18._MAX, EMAX)  // _MAX: Maximum Base Address
                CreateQWordField (RBUF, \_SB.EPC._Y18._LEN, ELEN)  // _LEN: Length
                EMIN = EMNA /* External reference */
                ELEN = ELNG /* External reference */
                EMAX = ((EMNA + ELNG) - One)
                Return (RBUF) /* \_SB_.EPC_.RBUF */
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If ((EPCS != Zero))
                {
                    Return (0x0F)
                }

                Return (Zero)
            }
        }
    }

I'm not aware that we would have an ACPI specification for SGX so this
is all I have at the moment (does not show any ACPI event for
hotplugging).

/Jarkko

  reply	other threads:[~2018-08-28 10:30 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 [this message]
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
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=20180828103040.GA21326@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.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: link
Be 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.