From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEEA6C43219 for ; Sun, 6 Mar 2022 16:53:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30C946B0071; Sun, 6 Mar 2022 11:53:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BC5F6B0072; Sun, 6 Mar 2022 11:53:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 184676B0073; Sun, 6 Mar 2022 11:53:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 087D36B0071 for ; Sun, 6 Mar 2022 11:53:27 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AA49F9A260 for ; Sun, 6 Mar 2022 16:53:26 +0000 (UTC) X-FDA: 79214557212.26.8E4E127 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf20.hostedemail.com (Postfix) with ESMTP id 12CC81C000A for ; Sun, 6 Mar 2022 16:53:25 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2A3BCB80E86; Sun, 6 Mar 2022 16:53:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61F83C340EC; Sun, 6 Mar 2022 16:53:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646585602; bh=MsFvCvDm3Ch69LnmbtaI1I9nqbcwEoILGdlAPzIetO8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y914rtUiHzXvBnz643r24P9/50ijdnH21BhkmMXNdPFnctYpw+CGGwkjiSO4OwtXJ cIj6IDXTGuX4ok/Azkkkz4yPB4UiDiPEI3ZnY1KuetY2NlaSDCT4alak24MLKqMMWT 81w5Bw17iwZvWhZno4RxV9EAK9enO5SHr8ultMzE3oiqsv18m8lefFW9p7UhVw52Rl P6T7XXKOZbWsN36s081JMMyXiGRVG5ePMhoUhLaFZ1j0EZtYdQz3Yxv9v0DV/r8mqd A923uLtITDotkTWx1rpjNsEoRnRjJwbB7SjCx/NcIAi4R8U3aH/UB0N3Tz2bKFyora Nys80UhGrEPVg== Date: Sun, 6 Mar 2022 18:52:41 +0200 From: 'Jarkko Sakkinen' To: David Laight Cc: "linux-mm@kvack.org" , Dave Hansen , Nathaniel McCallum , Reinette Chatre , Andrew Morton , "linux-sgx@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Florian Fainelli , Thomas Bogendoerfer , Matthew Auld , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , Daniel Vetter , Jason Ekstrand , Chris Wilson , Maarten Lankhorst , Greg Kroah-Hartman , Tvrtko Ursulin , Vasily Averin , Shakeel Butt , Michal Hocko , zhangyiru , Alexey Gladkov , Alexander Mikhalitsyn , "linux-mips@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "codalist@coda.cs.cmu.edu" , "linux-unionfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH RFC 0/3] MAP_POPULATE for device memory Message-ID: References: <20220306053211.135762-1-jarkko@kernel.org> <7f46ef3c80734f478501d21cef0182c5@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f46ef3c80734f478501d21cef0182c5@AcuMS.aculab.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 12CC81C000A X-Stat-Signature: 4soaqocfj8hfsnbe7dj6rgdtacoxqoia Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y914rtUi; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org X-HE-Tag: 1646585605-987198 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Mar 06, 2022 at 08:30:14AM +0000, David Laight wrote: > From: Jarkko Sakkinen > > Sent: 06 March 2022 05:32 > > > > For device memory (aka VM_IO | VM_PFNMAP) MAP_POPULATE does nothing. Allow > > to use that for initializing the device memory by providing a new callback > > f_ops->populate() for the purpose. > > > > SGX patches are provided to show the callback in context. > > > > An obvious alternative is a ioctl but it is less elegant and requires > > two syscalls (mmap + ioctl) per memory range, instead of just one > > (mmap). > > Is this all about trying to stop the vm_operations_struct.fault() > function being called? In SGX protected memory is actually encrypted normal memory and CPU access control semantics (marked as reserved, e.g. struct page's). In SGX you need call ENCLS[EAUG] outside the protected memory to add new pages to the protected memory. Then when CPU is executing inside this protected memory, also known as enclaves, it commits the memory as part of the enclave either with ENCLU[EACCEPT] or ENCLU[EACCEPTCOPY]. So the point is not prevent page faults but to prepare the memory for pending state so that the enclave can then accept them without round-trips, and in some cases thus improve performance (in our case in enarx.dev platform that we are developing). In fact, #PF handler in SGX driver in the current SGX2 patch set also does EAUG on-demand. Optimal is to have both routes available. And said, this can be of course also implemented as ioctl. BR, Jarkko