Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4097732imm; Wed, 5 Sep 2018 10:38:21 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYMl3JFLu6xdoCWQ39fR4LOB/qQfNmlQDYOAVCRrdonTkzEGXfrKAXz6SdEH/2AWZQ459BE X-Received: by 2002:a62:591a:: with SMTP id n26-v6mr41831402pfb.94.1536169101788; Wed, 05 Sep 2018 10:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536169101; cv=none; d=google.com; s=arc-20160816; b=g3Bw0CUdUjSbrnzI9K2dbLFuEbChOZ9ekJxvJXRsPHlcw9KaUoP2xLc7eVNQDImpz6 7AXJyozkZj5wkq2D97QKlwVTBn2oUTia/OLYC7Pahd6MaqU6Zss3r7TM9m+sqGyWIvVj rzJTQNX2lNqgE6AITC9HU+0/UNeST9fnIeVk42aMCkfR1ZDTAFMwJMT5vlOFXHL805Zk +DwLqsrXIVTegvJ8bxBgfHreVWF5VG+avTNW7T3ILLOu+yIYHOVt3uau2P4/cQKvvL9/ 9Q2HNVCaHasgl4KmYOXu0Ak+3OPmtRfV6VVsYZQD8IX9vx8WYK57ZVSEP0+wlJ0Ng0bt 7uSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=VyvkosiuFn+t0y5pmJfbBPZZd+KXyM1ieNfPs13BZk4=; b=Q9SFHfiCHpgL3slGm/6MxP8Z2v9MG4B/oJ4pX7UzhyEZkgQCdfJUeCtWfDLwq784MB tIu5wRuL6ez77HcV2XlpFAQzx4kLkwDWoVYY6na9q4l5J7cYKOkk6nnMq+Zeu3yhL2N3 DCPvv+WNMM6T5bVskWfEpJozsdV4gM24d/LJf46LvLYKDndZH/mLoohGWg6gykYQ9rmD T30dZIj5jieG9zm4D5gAoyIzfq77gNe2YF+vHq7ePTp5qIWXrLSWzLALV88Jr2aiXMNN zMBDXo5AH/vIlTgnhUplmQbrwkvMvaJhQh7D2Hf1QTHzHtW38lTZGMA4GHNEUkAq4zvS 75vQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 16-v6si2576969pgy.641.2018.09.05.10.38.06; Wed, 05 Sep 2018 10:38:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727790AbeIEWHX (ORCPT + 99 others); Wed, 5 Sep 2018 18:07:23 -0400 Received: from mga18.intel.com ([134.134.136.126]:5939 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726497AbeIEWHX (ORCPT ); Wed, 5 Sep 2018 18:07:23 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2018 10:36:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,334,1531810800"; d="scan'208";a="83311959" Received: from gsharm2-mobl1.amr.corp.intel.com (HELO localhost) ([10.249.37.218]) by fmsmga002.fm.intel.com with ESMTP; 05 Sep 2018 10:36:07 -0700 Date: Wed, 5 Sep 2018 20:36:06 +0300 From: Jarkko Sakkinen To: Sean Christopherson Cc: Andy Shevchenko , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Platform Driver , Dave Hansen , nhorman@redhat.com, npmccallum@redhat.com, linux-sgx@vger.kernel.org, serge.ayoun@intel.com, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , suresh.b.siddha@intel.com, Linux Kernel Mailing List Subject: Re: [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages Message-ID: <20180905173606.GF11368@linux.intel.com> References: <20180827185507.17087-1-jarkko.sakkinen@linux.intel.com> <20180827185507.17087-8-jarkko.sakkinen@linux.intel.com> <20180904174914.GA5690@linux.intel.com> <20180904181735.GA5820@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180904181735.GA5820@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 04, 2018 at 11:17:35AM -0700, Sean Christopherson wrote: > On Tue, Sep 04, 2018 at 09:01:15PM +0300, Andy Shevchenko wrote: > > On Tue, Sep 4, 2018 a> +/** > > > > > > > + va = ioremap_cache(addr, size); > > > > > + if (!va) > > > > > + return -ENOMEM; > > > > > > > > I'm not sure this is a right API. Do we operate with memory? Does it > > > > have I/O side effects? > > > > If no, memremap() would be better to use. > > > > > > Preserving __iomem is desirable. There aren't side effects per se, > > > but direct non-enclave accesses to the EPC get abort page semantics so > > > the kernel shouldn't be directly dereferencing a pointer to the EPC. > > > Though by that argument, sgx_epc_bank.va, sgx_epc_addr's return and > > > all ENCLS helpers should be tagged __iomem. > > > > Why? > > Does it related to *any* I/O? > > No, hence my other comment that __private or a new tag altogether may > be more appropriate. The noderef attribute is what we truly care > about. My proposal is that we go with memremap() and use #define __sgx_epc __attribute__((noderef)) It makes sense to check that direct EPC pointers are not passed to functions when they are not supposed to. /Jarkko