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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7358AC433FE for ; Mon, 7 Mar 2022 11:13:28 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BD26610F65B; Mon, 7 Mar 2022 11:13:19 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id C5CE010E6E4; 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 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-Mailman-Approved-At: Mon, 07 Mar 2022 11:13:15 +0000 Subject: Re: [Intel-gfx] [PATCH RFC 0/3] MAP_POPULATE for device memory X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Hocko , zhangyiru , Daniel Vetter , Dave Hansen , "dri-devel@lists.freedesktop.org" , Chris Wilson , "linux-mm@kvack.org" , Alexander Mikhalitsyn , Florian Fainelli , "linux-unionfs@vger.kernel.org" , "codalist@coda.cs.cmu.edu" , Matthew Auld , Vasily Averin , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , "intel-gfx@lists.freedesktop.org" , "linux-mips@vger.kernel.org" , Shakeel Butt , Reinette Chatre , "linux-sgx@vger.kernel.org" , Thomas Bogendoerfer , Nathaniel McCallum , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Andrew Morton , Alexey Gladkov Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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