Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753799AbdLSX55 (ORCPT ); Tue, 19 Dec 2017 18:57:57 -0500 Received: from mga09.intel.com ([134.134.136.24]:45479 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753041AbdLSX54 (ORCPT ); Tue, 19 Dec 2017 18:57:56 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,429,1508828400"; d="scan'208";a="3866173" Message-ID: <1513727868.2206.33.camel@linux.intel.com> Subject: Re: [PATCH v9 7/7] intel_sgx: in-kernel launch enclave From: Jarkko Sakkinen To: Andy Shevchenko Cc: intel-sgx-kernel-dev@lists.01.org, Platform Driver , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Darren Hart , Andy Shevchenko Date: Wed, 20 Dec 2017 01:57:48 +0200 In-Reply-To: References: <20171216162200.20243-1-jarkko.sakkinen@linux.intel.com> <20171216162200.20243-8-jarkko.sakkinen@linux.intel.com> <20171219135928.ospmfhabavac5gnu@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.1-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1396 Lines: 32 On Tue, 2017-12-19 at 17:36 +0200, Andy Shevchenko wrote: > On Tue, Dec 19, 2017 at 3:59 PM, Jarkko Sakkinen > wrote: > > > I streamlined the IPC quite a bit. See the attached patch. Can be > > applied on top of this patch. > > Sorry, I didn't look into actual code, but WRT the attached patch, > wouldn't be better / possible to use > pr_fmt() to print "intel_sgx:" prefix for all pr_*() ? Would make much sense. I can do this. In any case Ineed to update this series at least once more for the copyright platters. Thanks for the comment. Now that the series does not add anything intrusive (namely pipe exports or use a fragile AES implementation) I would propose to pull the current series as a single platform driver and move relevant code under arch/x86 in subsequent series. I've taken great of making sure that it would be doable to move code later on when I first decided to make it as a plaform driver. My thinking has been that encapsulating the codebase to a driver would be the least intrusive way to mainline the first version of the SGX support for the Linux kernel especially when there isn't publicly available HW to test it yet with launch control that makes sense for Linux. I can write a detailed description to the documentation how the implementation works in order to help to make the right decision for subsequent series. /Jarkko