Re: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver
diff --git a/m b/m
index 1ea4786..8456a38 100644
--- a/m
+++ b/m
@@ -1,43 +1,38 @@
-Return-Path: <SRS0=01IT=SZ=vger.kernel.org=linux-sgx-owner@kernel.org>
+Return-Path: <SRS0=QZjA=S2=vger.kernel.org=linux-sgx-owner@kernel.org>
 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
 	aws-us-west-2-korg-lkml-1.web.codeaurora.org
 X-Spam-Level: 
-X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,
-	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,
-	URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0
+X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
+	MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT
+	autolearn=ham autolearn_force=no version=3.4.0
 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
-	by smtp.lore.kernel.org (Postfix) with ESMTP id 9CA9FC282DD
-	for <linux-sgx@archiver.kernel.org>; Tue, 23 Apr 2019 23:29:34 +0000 (UTC)
+	by smtp.lore.kernel.org (Postfix) with ESMTP id 86A74C10F03
+	for <linux-sgx@archiver.kernel.org>; Wed, 24 Apr 2019 00:26:55 +0000 (UTC)
 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
-	by mail.kernel.org (Postfix) with ESMTP id 545ED218DA
-	for <linux-sgx@archiver.kernel.org>; Tue, 23 Apr 2019 23:29:34 +0000 (UTC)
-Authentication-Results: mail.kernel.org;
-	dkim=pass (1024-bit key) header.d=fortanix.onmicrosoft.com header.i=@fortanix.onmicrosoft.com header.b="fhpejLJC"
+	by mail.kernel.org (Postfix) with ESMTP id 567462148D
+	for <linux-sgx@archiver.kernel.org>; Wed, 24 Apr 2019 00:26:55 +0000 (UTC)
 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
-        id S1729136AbfDWX33 (ORCPT <rfc822;linux-sgx@archiver.kernel.org>);
-        Tue, 23 Apr 2019 19:29:29 -0400
-Received: from mail-eopbgr690117.outbound.protection.outlook.com ([40.107.69.117]:8864
-        "EHLO NAM04-CO1-obe.outbound.protection.outlook.com"
-        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
-        id S1728876AbfDWX33 (ORCPT <rfc822;linux-sgx@vger.kernel.org>);
-        Tue, 23 Apr 2019 19:29:29 -0400
-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
- d=fortanix.onmicrosoft.com; s=selector1-fortanix-com;
- h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
- bh=gxrfkcAqxb2uYlZHchp9MU7ftrB5QJbBFQnIu6rDrbk=;
- b=fhpejLJCrYNsdynKIc/PqIGM+FIzyh2J4Az7GCJ+XMyHJCbORDCNz1UH5k0y9/m6mG349ZPiAx5UDFLj44/c6FQ7hC/ODEyQtx9dKETmjpa3wRAEl9sPWFvjCF/pU/XMKTJ4qgFV2nbARw6UL6jLNl68POWJQMaJeJ4ygpwyRqs=
-Received: from SN6PR11MB3167.namprd11.prod.outlook.com (52.135.109.144) by
- SN6PR11MB3101.namprd11.prod.outlook.com (52.135.126.203) with Microsoft SMTP
- Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
- 15.20.1813.17; Tue, 23 Apr 2019 23:29:24 +0000
-Received: from SN6PR11MB3167.namprd11.prod.outlook.com
- ([fe80::11b:a687:cd42:570d]) by SN6PR11MB3167.namprd11.prod.outlook.com
- ([fe80::11b:a687:cd42:570d%3]) with mapi id 15.20.1813.017; Tue, 23 Apr 2019
- 23:29:24 +0000
-From:   Jethro Beekman <jethro@fortanix.com>
-To:     Sean Christopherson <sean.j.christopherson@intel.com>,
-        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
-CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
+        id S1728536AbfDXA0z (ORCPT <rfc822;linux-sgx@archiver.kernel.org>);
+        Tue, 23 Apr 2019 20:26:55 -0400
+Received: from mga12.intel.com ([192.55.52.136]:57120 "EHLO mga12.intel.com"
+        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
+        id S1726339AbfDXA0z (ORCPT <rfc822;linux-sgx@vger.kernel.org>);
+        Tue, 23 Apr 2019 20:26:55 -0400
+X-Amp-Result: UNKNOWN
+X-Amp-Original-Verdict: FILE UNKNOWN
+X-Amp-File-Uploaded: False
+Received: from fmsmga004.fm.intel.com ([10.253.24.48])
+  by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Apr 2019 17:26:54 -0700
+X-ExtLoop1: 1
+X-IronPort-AV: E=Sophos;i="5.60,387,1549958400"; 
+   d="scan'208";a="164464910"
+Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.181])
+  by fmsmga004.fm.intel.com with ESMTP; 23 Apr 2019 17:26:53 -0700
+Date:   Tue, 23 Apr 2019 17:26:53 -0700
+From:   Sean Christopherson <sean.j.christopherson@intel.com>
+To:     Jethro Beekman <jethro@fortanix.com>
+Cc:     Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
+        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
         "x86@kernel.org" <x86@kernel.org>,
         "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
         "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
@@ -57,212 +52,93 @@
         "kai.huang@intel.com" <kai.huang@intel.com>,
         "rientjes@google.com" <rientjes@google.com>
 Subject: Re: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver
-Thread-Topic: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver
-Thread-Index: AQHU9Qombksy6NSZXkyI7LD5DH8ik6ZIwveAgAGrtoA=
-Date:   Tue, 23 Apr 2019 23:29:24 +0000
-Message-ID: <6dd981a7-0e38-1273-45c1-b2c0d8bf6fed@fortanix.com>
+Message-ID: <20190424002653.GB14422@linux.intel.com>
 References: <20190417103938.7762-1-jarkko.sakkinen@linux.intel.com>
  <20190417103938.7762-16-jarkko.sakkinen@linux.intel.com>
  <20190422215831.GL1236@linux.intel.com>
-In-Reply-To: <20190422215831.GL1236@linux.intel.com>
-Accept-Language: en-US
-Content-Language: en-US
-X-MS-Has-Attach: yes
-X-MS-TNEF-Correlator: 
-x-clientproxiedby: BYAPR08CA0037.namprd08.prod.outlook.com
- (2603:10b6:a03:117::14) To SN6PR11MB3167.namprd11.prod.outlook.com
- (2603:10b6:805:c4::16)
-authentication-results: spf=none (sender IP is )
- smtp.mailfrom=jethro@fortanix.com; 
-x-ms-exchange-messagesentrepresentingtype: 1
-x-originating-ip: [67.207.107.146]
-x-ms-publictraffictype: Email
-x-ms-office365-filtering-correlation-id: caaf75e6-6155-4760-f156-08d6c843853d
-x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020);SRVR:SN6PR11MB3101;
-x-ms-traffictypediagnostic: SN6PR11MB3101:
-x-microsoft-antispam-prvs: <SN6PR11MB3101B8E65978828C08F4984AAA230@SN6PR11MB3101.namprd11.prod.outlook.com>
-x-forefront-prvs: 0016DEFF96
-x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(39850400004)(396003)(136003)(346002)(376002)(366004)(199004)(189003)(386003)(446003)(186003)(26005)(64756008)(486006)(11346002)(6506007)(53546011)(6116002)(102836004)(476003)(52116002)(53936002)(14454004)(99936001)(2616005)(36756003)(3846002)(66476007)(66556008)(66616009)(508600001)(66446008)(4326008)(2906002)(66066001)(73956011)(110136005)(54906003)(71200400001)(8676002)(68736007)(316002)(6306002)(6486002)(81166006)(31696002)(6512007)(5660300002)(31686004)(99286004)(66946007)(81156014)(8936002)(86362001)(71190400001)(305945005)(76176011)(256004)(6246003)(7416002)(25786009)(7736002)(229853002)(97736004)(14444005)(6436002)(966005);DIR:OUT;SFP:1102;SCL:1;SRVR:SN6PR11MB3101;H:SN6PR11MB3167.namprd11.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
-received-spf: None (protection.outlook.com: fortanix.com does not designate
- permitted sender hosts)
-x-ms-exchange-senderadcheck: 1
-x-microsoft-antispam-message-info: FJIQMPYgsDaus7yo9jBMyfbsNJfwfevmDjFWLPZUcwSG35EdMold/MPvSKUh0eOSmpw82kw+rTDetCnsqDtBpMXT0r9QOW6+4i2CNuvlSbdUi0cDmskdEGuLPnAhCIjCsOkvZa7flLo7E6tAxRR9nVblLbri3bq6D5fM7JNnsaY3n6luvWPerCVo1qWKEnTTA+50lzW+Hh9n6EpsiK3tJg4SroDL39hGdqs62P7bgEHCEo3xnhPL3TYbFbrYleVI1kuOiiedD69cjpeUCQYnWcUqMrN7zV2RVtAs27bbKb4I/BYoTMaJy75cqPLTPJfcaUfhBlae9ynA9Z6VwV0yxZksHoKdJwhjobi3vqtv/IIdk+CRO9qAFsrX7A/t9CnfNleIvqktc6gHSEGcsXiD5uizSmqrIt34GPW2nAj0xOc=
-Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090407000907020403000705"
+ <6dd981a7-0e38-1273-45c1-b2c0d8bf6fed@fortanix.com>
 MIME-Version: 1.0
-X-OriginatorOrg: fortanix.com
-X-MS-Exchange-CrossTenant-Network-Message-Id: caaf75e6-6155-4760-f156-08d6c843853d
-X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 23:29:24.6579
- (UTC)
-X-MS-Exchange-CrossTenant-fromentityheader: Hosted
-X-MS-Exchange-CrossTenant-id: de7becae-4883-43e8-82c7-7dbdbb988ae6
-X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
-X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3101
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <6dd981a7-0e38-1273-45c1-b2c0d8bf6fed@fortanix.com>
+User-Agent: Mutt/1.5.24 (2015-08-30)
 Sender: linux-sgx-owner@vger.kernel.org
 Precedence: bulk
 List-ID: <linux-sgx.vger.kernel.org>
 X-Mailing-List: linux-sgx@vger.kernel.org
 
---------------ms090407000907020403000705
-Content-Type: text/plain; charset=utf-8; format=flowed
-Content-Language: en-US
-Content-Transfer-Encoding: quoted-printable
+On Tue, Apr 23, 2019 at 11:29:24PM +0000, Jethro Beekman wrote:
+> On 2019-04-22 14:58, Sean Christopherson wrote:
+> >+Cc Jethro
+> >
+> >On Wed, Apr 17, 2019 at 01:39:25PM +0300, 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 the CPU access control.
+> >>
+> >>This commit adds the Linux SGX Enclave Driver that provides an ioctl API
+> >>to manage enclaves. The address range for an enclave, commonly referred
+> >>as ELRANGE in the documentation (e.g. Intel SDM), is reserved with
+> >>mmap() against /dev/sgx/enclave. After that a set ioctls is used to
+> >>build the enclave to the ELRANGE.
+> >>
+> >>Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+> >>Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
+> >>Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+> >>Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
+> >>Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
+> >>Co-developed-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
+> >>Signed-off-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
+> >>Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
+> >>Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+> >>---
+> >
+> >...
+> >
+> >>+#ifdef CONFIG_ACPI
+> >>+static struct acpi_device_id sgx_device_ids[] = {
+> >>+	{"INT0E0C", 0},
+> >>+	{"", 0},
+> >>+};
+> >>+MODULE_DEVICE_TABLE(acpi, sgx_device_ids);
+> >>+#endif
+> >>+
+> >>+static struct platform_driver sgx_drv = {
+> >>+	.probe = sgx_drv_probe,
+> >>+	.remove = sgx_drv_remove,
+> >>+	.driver = {
+> >>+		.name			= "sgx",
+> >>+		.acpi_match_table	= ACPI_PTR(sgx_device_ids),
+> >>+	},
+> >>+};
+> >
+> >Where do we stand on removing the ACPI and platform_driver dependencies?
+> >Can we get rid of them sooner rather than later?
+> 
+> You know my position on this...
+> https://www.spinics.net/lists/linux-sgx/msg00624.html . I don't really have
+> any new arguments.
+> 
+> Considering the amount of planned changes for the driver post-merge, I think
+> it's crucial that the driver part can be swapped out with alternative
+> implementations.
 
-On 2019-04-22 14:58, Sean Christopherson wrote:
-> +Cc Jethro
->=20
-> On Wed, Apr 17, 2019 at 01:39:25PM +0300, Jarkko Sakkinen wrote:
->> Intel Software Guard eXtensions (SGX) is a set of CPU instructions tha=
-t
->> 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 the CPU access control.
->>
->> This commit adds the Linux SGX Enclave Driver that provides an ioctl A=
-PI
->> to manage enclaves. The address range for an enclave, commonly referre=
-d
->> as ELRANGE in the documentation (e.g. Intel SDM), is reserved with
->> mmap() against /dev/sgx/enclave. After that a set ioctls is used to
->> build the enclave to the ELRANGE.
->>
->> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
->> Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>=
+This gets far outside of my area of expertise as I think this is more of
+a policy question as opposed to a technical question, e.g. do we export
+function simply to allow out-of-tree alternatives.
 
->> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
->> Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
->> Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
->> Co-developed-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
->> Signed-off-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
->> Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
->> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
->> ---
->=20
-> ...
->=20
->> +#ifdef CONFIG_ACPI
->> +static struct acpi_device_id sgx_device_ids[] =3D {
->> +	{"INT0E0C", 0},
->> +	{"", 0},
->> +};
->> +MODULE_DEVICE_TABLE(acpi, sgx_device_ids);
->> +#endif
->> +
->> +static struct platform_driver sgx_drv =3D {
->> +	.probe =3D sgx_drv_probe,
->> +	.remove =3D sgx_drv_remove,
->> +	.driver =3D {
->> +		.name			=3D "sgx",
->> +		.acpi_match_table	=3D ACPI_PTR(sgx_device_ids),
->> +	},
->> +};
->=20
-> Where do we stand on removing the ACPI and platform_driver dependencies=
-?
-> Can we get rid of them sooner rather than later?
+> >Now that the core SGX code is approaching stability, I'd like to start
+> >sending RFCs for the EPC virtualization and KVM bits to hash out that side
+> >of things.  The ACPI crud is the last chunk of code that would require
+> >non-trivial changes to the core SGX code for the proposed virtualization
+> >implementation.  I'd strongly prefer to get it out of the way before
+> >sending the KVM RFCs.
+> 
+> What kind of changes? Wouldn't KVM just be another consumer of the same API
+> used by the driver?
 
-You know my position on this...=20
-https://www.spinics.net/lists/linux-sgx/msg00624.html . I don't really=20
-have any new arguments.
-
-Considering the amount of planned changes for the driver post-merge, I=20
-think it's crucial that the driver part can be swapped out with=20
-alternative implementations.
-
-> Now that the core SGX code is approaching stability, I'd like to start
-> sending RFCs for the EPC virtualization and KVM bits to hash out that s=
-ide
-> of things.  The ACPI crud is the last chunk of code that would require
-> non-trivial changes to the core SGX code for the proposed virtualizatio=
-n
-> implementation.  I'd strongly prefer to get it out of the way before
-> sending the KVM RFCs.
-
-What kind of changes? Wouldn't KVM just be another consumer of the same=20
-API used by the driver?
-
---
-Jethro Beekman | Fortanix
-
-
---------------ms090407000907020403000705
-Content-Type: application/pkcs7-signature; name="smime.p7s"
-Content-Transfer-Encoding: base64
-Content-Disposition: attachment; filename="smime.p7s"
-Content-Description: S/MIME Cryptographic Signature
-
-MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
-Cx8wggUxMIIEGaADAgECAhBdZC9mIseKJlmxx1xn+g00MA0GCSqGSIb3DQEBCwUAMIGXMQsw
-CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
-b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD
-bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODA5MTUwMDAw
-MDBaFw0xOTA5MTUyMzU5NTlaMCQxIjAgBgkqhkiG9w0BCQEWE2pldGhyb0Bmb3J0YW5peC5j
-b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRQDOQsroKjy2xAQCXLyqryJt4
-Xwj8hcweJCzOnjILKHIoWlOQ0b9yIbFLIWBRt/9zdxlE5ZabDVHnkIyhcVgtU/BA73e78Wx2
-LOObdg0wfs9U2CVRYhz2EPHFjGvkYKihItt69ye91hj1w7RKCrYC8KZGSZ/+sbkJzQdXVy32
-lxmiNEt17GNRebpkJCaFnznd6C2a8tBAS2Fa/UNyFdEs4eoRoYSKswclRhbe81aVhqY2hjcd
-O6puyyaYp5hkmau2UPih6OpRSOhbe6Tuebceg1yvumoVX3OZtGPS1VdQ+p0bxB0RE6gNs140
-ZKUhrvAJDETuGaaQD4A2/6ksLunjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBSCr2yM+MX+
-lmF86B89K3FIXsSLwDAdBgNVHQ4EFgQUsFUcmGtaJBU7/52LyTYHC/M+LscwDgYDVR0PAQH/
-BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC
-MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG
-AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBaBgNVHR8EUzBRME+gTaBL
-hklodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv
-bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGLBggrBgEFBQcBAQR/MH0wVQYIKwYBBQUHMAKGSWh0
-dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k
-U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv
-bTAeBgNVHREEFzAVgRNqZXRocm9AZm9ydGFuaXguY29tMA0GCSqGSIb3DQEBCwUAA4IBAQB6
-v3tFEUSGv9+yY4wUjvcMyz3126nJrX5LkfEvrnCEpEiImECuoYvxOYNLYYynell7BQGtTaZg
-shMfDvwpy2isoi3w1AWAfbn6npnSKLzu0BMRvcCPWY8VPmePPizTqXoPkLwgTJfSaWkxMP1u
-rfL9S5NeRdkjwjHklX5IWuwwDu1hsKVZrxSSY2unCtvq67UHWz+z6rG1JQrP2YDfb98xun3y
-eLBNe/LFBNnGISbkT5q6D+e5c0bgzoH9nH4bsw3t8aDqJTfT3BqQdWr4pF05ODzzeOmEqeYE
-qGlD9hIL2AbmTZLjunAnARr6Fv7Sfqt23ptsGkmoZ9ZQNjT3TlwvMIIF5jCCA86gAwIBAgIQ
-apvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkGA1UEBhMCR0IxGzAZBgNV
-BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N
-T0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRo
-b3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCBlzELMAkGA1UEBhMCR0Ix
-GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
-ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhl
-bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
-ggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpYPpynMS6n9jR22YRq2tA9
-NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1wgOkUMgzKlWlVJGyK+Ul
-NEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL55AqLPikFlgqOtzk06kb2
-qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP1cHWse9tGKTDyUGg2hJZ
-jrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5LFLG3yQK+xS1AgMBAAGj
-ggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy1DAdBgNVHQ4EFgQUgq9s
-jPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAw
-EQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9jcmwuY29tb2Rv
-Y2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHEGCCsGAQUFBwEB
-BGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQWRk
-VHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTANBgkq
-hkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJCAbU2C81zd9A/tNx4+js
-QgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/hk6zSPwIal9v5IkDcZoFD
-7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWlnhMpIMwpWZT89RY0wpJO
-+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNmNppI4ZNMUH4Tam85S1j6
-E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tUU1gb4jfWCcyvB8czm12F
-gX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR6MvnzS6X72HP0PRLRTiO
-SEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ16HO5m60ttl1Enk8MQkz
-/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8aorYew6CQvdVifC3HtwlSa
-m9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5v7zmEVDNXFnHn9tFpMpO
-UvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfKehIxggQ1MIIEMQIBATCB
-rDCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
-BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9E
-TyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEF1kL2Yi
-x4omWbHHXGf6DTQwDQYJYIZIAWUDBAIBBQCgggJZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
-BwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDQyMzIzMjkyMVowLwYJKoZIhvcNAQkEMSIEINKOiLoc
-pV/22RD7jPCIuHcHJ1hp9hxfzNIm07BS0lhcMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUD
-BAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
-AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgb0GCSsGAQQBgjcQBDGBrzCBrDCBlzEL
-MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
-Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
-Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEF1kL2Yix4omWbHH
-XGf6DTQwgb8GCyqGSIb3DQEJEAILMYGvoIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
-R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
-Q0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
-YW5kIFNlY3VyZSBFbWFpbCBDQQIQXWQvZiLHiiZZscdcZ/oNNDANBgkqhkiG9w0BAQEFAASC
-AQAqRW2bTz/fz8sV8+ftunLCAqKnSuAVlpuuRqHFoN27WCmY+8N7DpLzND+iahEG/Kw5KyLQ
-4/RQMROOv5x2kJli/xWgMzeu+suLyo16IrqV0FIy7js+BvywOFT/3w+0q5Mf2EP8au19Gr4m
-FWfrOywDHPTg2SzXFrslBnnKUBfTRDQ89p8/fMC6DHbghwJqCWpA/YIKPGiuk3BsC72ldc/x
-Mkk/tryV298daRQr788faV38NCEJHzunzCrExI9TQuQje2dcO4Dd0B6sqz7n/dQaz7rMOc++
-QfUni4KYENb05BTw9dXTtQ6VMAIecoc8HDQfEGWtiQPPxvyGeYxSNVT1AAAAAAAA
-
---------------ms090407000907020403000705--
+Nope, userspace "only" needs to be able to mmap() arbitrary chunks of EPC.
+Except for EPC management, which is already in built into the kernel, the
+EPC virtualization code has effectively zero overlap with the driver.  Of
+course this is all technically speculative since none of this is upstream...