Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752458AbcD2WWu (ORCPT ); Fri, 29 Apr 2016 18:22:50 -0400 Received: from jbeekman.nl ([149.210.172.151]:52657 "EHLO daxilon.jbeekman.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751829AbcD2WWs (ORCPT ); Fri, 29 Apr 2016 18:22:48 -0400 To: Jarkko Sakkinen , Jethro Beekman References: <1461605698-12385-1-git-send-email-jarkko.sakkinen@linux.intel.com> <1461605698-12385-4-git-send-email-jarkko.sakkinen@linux.intel.com> <57206102.3050507@jbeekman.nl> <20160427124056.GA22003@intel.com> <57214C07.8090806@jbeekman.nl> <20160429200449.GB27821@intel.com> Cc: gregkh@linuxfoundation.org, "open list:STAGING SUBSYSTEM" , "maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT" , "open list:X86 ARCHITECTURE 32-BIT AND 64-BIT" , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner From: Jethro Beekman X-Enigmail-Draft-Status: N1110 Message-ID: <5723DE9B.7030102@jbeekman.nl> Date: Fri, 29 Apr 2016 15:22:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160429200449.GB27821@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2620:0:1002:fd01:a044:f1ea:3972:9aef X-SA-Exim-Mail-From: kernel@jbeekman.nl X-Spam-Report: Content analysis details: (-1.0 points, 5.0 required) pts rule name description --- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Subject: Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 829 Lines: 21 On 29-04-16 13:04, Jarkko Sakkinen wrote: >>> Why would you want to do that? >> >> ... > > Do you see this as a performance issue or why do you think that this > would hurt that much? I don't think it's a performance issue at all. I'm just giving an example of why you'd want to do this. I'm sure people who want to use this instruction set can come up with other uses, so I think the driver should support it. Other drivers on different platform might support this, in which case we should be compatible (to achieve the same enclave measurement). Other Linux drivers support it [1]. I would ask: why would you not want to do this? It seems trivial to expand the current flag into 16 separate flags; one for each 256-byte chunk in the page. [1] https://github.com/jethrogb/sgx-utils/tree/master/linux-driver > /Jarkko Jethro