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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69909C4360F for ; Wed, 3 Apr 2019 16:07:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2DF0C206B7 for ; Wed, 3 Apr 2019 16:07:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RBkUvVUo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DF0C206B7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eYTHOZJwzhUAAa9/w3XLtrY8BgBCJJB6Yg1/aof1m+E=; b=RBkUvVUoyiAjhW NW1TqkG/8spN74toy5lbsPxEqHpVjEa2are7saabIii0rGHXHMZrxLXzJcI4NP9bIdjE5K5W2bqpJ CfL7cs1xt4DTJAnXIUQSAF+E/lsHQoGC551IgeItNjf/pY99qYN3bTqpUjTsY2pNFd4KEJaJBmX15 /hQKEgnEElpAkc6VbeTeWJkVBmXk0JW6+ATtJ0euSqm6O1QapQrIWmvx2ykIr76dsFAUKaIrfA4l/ h8XOwyp0DdvfxvpVehv39F4yNYzm11uLACawsFv16fwefQS6jXqNjQy2gme7z4hlsfAU2+Dhq3PdJ Vx15a5Jt+Lomz+yQALHA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBiQN-0003Jc-Uz; Wed, 03 Apr 2019 16:07:39 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBiQL-0003HM-E5 for linux-arm-kernel@lists.infradead.org; Wed, 03 Apr 2019 16:07:38 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 478CB88AAE; Wed, 3 Apr 2019 16:07:31 +0000 (UTC) Received: from redhat.com (ovpn-125-190.rdu2.redhat.com [10.10.125.190]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AF99B608A5; Wed, 3 Apr 2019 16:07:24 +0000 (UTC) Date: Wed, 3 Apr 2019 12:07:22 -0400 From: Jerome Glisse To: Robin Murphy Subject: Re: [PATCH 6/6] arm64/mm: Enable ZONE_DEVICE Message-ID: <20190403160722.GB12818@redhat.com> References: <1554265806-11501-1-git-send-email-anshuman.khandual@arm.com> <1554265806-11501-7-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 03 Apr 2019 16:07:32 +0000 (UTC) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190403_090737_511431_9CF372BC X-CRM114-Status: GOOD ( 22.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, mhocko@suse.com, Anshuman Khandual , catalin.marinas@arm.com, david@redhat.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, cai@lca.pw, linux-mm@kvack.org, logang@deltatee.com, james.morse@arm.com, cpandya@codeaurora.org, arunks@codeaurora.org, akpm@linux-foundation.org, mgorman@techsingularity.net, dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org, osalvador@suse.de Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 03, 2019 at 02:58:28PM +0100, Robin Murphy wrote: > [ +Dan, Jerome ] > = > On 03/04/2019 05:30, Anshuman Khandual wrote: > > Arch implementation for functions which create or destroy vmemmap mappi= ng > > (vmemmap_populate, vmemmap_free) can comprehend and allocate from inside > > device memory range through driver provided vmem_altmap structure which > > fulfils all requirements to enable ZONE_DEVICE on the platform. Hence j= ust > = > ZONE_DEVICE is about more than just altmap support, no? > = > > enable ZONE_DEVICE by subscribing to ARCH_HAS_ZONE_DEVICE. But this is = only > > applicable for ARM64_4K_PAGES (ARM64_SWAPPER_USES_SECTION_MAPS) only wh= ich > > creates vmemmap section mappings and utilize vmem_altmap structure. > = > What prevents it from working with other page sizes? One of the foremost > use-cases for our 52-bit VA/PA support is to enable mapping large quantit= ies > of persistent memory, so we really do need this for 64K pages too. FWIW, = it > appears not to be an issue for PowerPC. > = > > Signed-off-by: Anshuman Khandual > > --- > > arch/arm64/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > = > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > index db3e625..b5d8cf5 100644 > > --- a/arch/arm64/Kconfig > > +++ b/arch/arm64/Kconfig > > @@ -31,6 +31,7 @@ config ARM64 > > select ARCH_HAS_SYSCALL_WRAPPER > > select ARCH_HAS_TEARDOWN_DMA_OPS if IOMMU_SUPPORT > > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST > > + select ARCH_HAS_ZONE_DEVICE if ARM64_4K_PAGES > = > IIRC certain configurations (HMM?) don't even build if you just turn this= on > alone (although of course things may have changed elsewhere in the meanti= me) > - crucially, though, from previous discussions[1] it seems fundamentally > unsafe, since I don't think we can guarantee that nobody will touch the > corners of ZONE_DEVICE that also require pte_devmap in order not to go > subtly wrong. I did get as far as cooking up some patches to sort that out > [2][3] which I never got round to posting for their own sake, so please > consider picking those up as part of this series. Correct _do not_ enable ZONE_DEVICE without support for pte_devmap detectio= n. If you want some feature of ZONE_DEVICE. Like HMM as while DAX does require pte_devmap, HMM device private does not. So you would first have to split ZONE_DEVICE into more sub-features kconfig option. What is the end use case you are looking for ? Persistent memory ? Cheers, J=E9r=F4me _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel