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=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 2AEF7C433E0 for ; Wed, 12 Aug 2020 07:38:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DCFFF2065C for ; Wed, 12 Aug 2020 07:38:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="YguUNolP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCFFF2065C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4E8686B00C0; Wed, 12 Aug 2020 03:38:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 498136B00C1; Wed, 12 Aug 2020 03:38:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D6008D0001; Wed, 12 Aug 2020 03:38:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 27C5D6B00C0 for ; Wed, 12 Aug 2020 03:38:53 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id C64B9181AEF15 for ; Wed, 12 Aug 2020 07:38:52 +0000 (UTC) X-FDA: 77141114904.11.owl02_5c0218e26fe9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 9C29D180F8B80 for ; Wed, 12 Aug 2020 07:38:52 +0000 (UTC) X-HE-Tag: owl02_5c0218e26fe9 X-Filterd-Recvd-Size: 7747 Received: from esa4.hc3370-68.iphmx.com (esa4.hc3370-68.iphmx.com [216.71.155.144]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Aug 2020 07:38:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1597217931; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=ShS55PgjfRlFMa0DNNlsr2fNiXMtncLBQuylfP4nMGg=; b=YguUNolPD2jCAK+7MU0rvIJxQezvWSL2K6zqNjG38/AvlgCZ1IbO+XZd wULZOAPMXD2rZ+GM2PgPT5nJNo6M0tRxniuAMbf1TF6tQHNYCMVtvVnNQ 7qblF+JEXTQXpRYMrol1iQVeSdWlpdLyMUcz1JX2nrWj2d1t/yiG9033O 0=; Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Zs2JsfV+aYnUe+nzG0vfzUdX+ziwoLc3xTEPPEd+NVtYmHmJw+DPYdtS53l1QsrvC/Zxz4eN0/ A0/nYWVhhDhtycBIX5cmj7XnFzCd0Cbb9CH7NwXunAwDyHJJYQcc69T5BEuEcNMl8PWfoSXX+s P7nimTSw40cj4SIbcq/qPkr5JpUauoYCGPpqjzp636wYVroZhErGaj15aTi03BxPwveV7Lcj6n s5xgeyApZtCvlmTWosFQMCqnPUJNCVpRHE5Lz4/jbls9uJTBhbW/oNcnDDvw5BOIArvG6fykiH 5D8= X-SBRS: 2.7 X-MesageID: 25254199 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.76,303,1592884800"; d="scan'208";a="25254199" Date: Wed, 12 Aug 2020 09:38:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= CC: , Oleksandr Andrushchenko , David Airlie , "Daniel Vetter" , Boris Ostrovsky , Stefano Stabellini , Dan Carpenter , Wei Liu , Yan Yankovskyi , , , , David Hildenbrand , Michal Hocko , Dan Williams Subject: Re: [PATCH v4 2/2] xen: add helpers to allocate unpopulated memory Message-ID: <20200812073840.GA975@Air-de-Roger> References: <20200811094447.31208-1-roger.pau@citrix.com> <20200811094447.31208-3-roger.pau@citrix.com> <7c9a25fa-c52c-66d2-3b03-14a59e069ab6@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <7c9a25fa-c52c-66d2-3b03-14a59e069ab6@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-Rspamd-Queue-Id: 9C29D180F8B80 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 Content-Transfer-Encoding: quoted-printable 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 Wed, Aug 12, 2020 at 09:28:45AM +0200, J=C3=BCrgen Gro=C3=9F wrote: > On 11.08.20 11:44, Roger Pau Monne wrote: > > To be used in order to create foreign mappings. This is based on the > > ZONE_DEVICE facility which is used by persistent memory devices in > > order to create struct pages and kernel virtual mappings for the IOME= M > > areas of such devices. Note that on kernels without support for > > ZONE_DEVICE Xen will fallback to use ballooned pages in order to > > create foreign mappings. > >=20 > > The newly added helpers use the same parameters as the existing > > {alloc/free}_xenballooned_pages functions, which allows for in-place > > replacement of the callers. Once a memory region has been added to be > > used as scratch mapping space it will no longer be released, and page= s > > returned are kept in a linked list. This allows to have a buffer of > > pages and prevents resorting to frequent additions and removals of > > regions. > >=20 > > If enabled (because ZONE_DEVICE is supported) the usage of the new > > functionality untangles Xen balloon and RAM hotplug from the usage of > > unpopulated physical memory ranges to map foreign pages, which is the > > correct thing to do in order to avoid mappings of foreign pages depen= d > > on memory hotplug. > >=20 > > Note the driver is currently not enabled on Arm platforms because it > > would interfere with the identity mapping required on some platforms. > >=20 > > Signed-off-by: Roger Pau Monn=C3=A9 > > --- > > Cc: Oleksandr Andrushchenko > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Boris Ostrovsky > > Cc: Juergen Gross > > Cc: Stefano Stabellini > > Cc: Dan Carpenter > > Cc: Roger Pau Monne > > Cc: Wei Liu > > Cc: Yan Yankovskyi > > Cc: dri-devel@lists.freedesktop.org > > Cc: xen-devel@lists.xenproject.org > > Cc: linux-mm@kvack.org > > Cc: David Hildenbrand > > Cc: Michal Hocko > > Cc: Dan Williams > > --- > > Changes since v3: > > - Introduce a Kconfig option that gates the addition of the > > unpopulated alloc driver. This allows to easily disable it on Arm > > platforms. > > - Dropped Juergen RB due to the addition of the Kconfig option. > > - Switched from MEMORY_DEVICE_DEVDAX to MEMORY_DEVICE_GENERIC. > >=20 > > Changes since v2: > > - Drop BUILD_BUG_ON regarding PVMMU page sizes. > > - Use a SPDX license identifier. > > - Call fill with only the minimum required number of pages. > > - Include xen.h header in xen_drm_front_gem.c. > > - Use less generic function names. > > - Exit early from the init function if not a PV guest. > > - Don't use all caps for region name. > > --- > > drivers/gpu/drm/xen/xen_drm_front_gem.c | 9 +- > > drivers/xen/Kconfig | 4 + > > drivers/xen/Makefile | 1 + > > drivers/xen/balloon.c | 4 +- > > drivers/xen/grant-table.c | 4 +- > > drivers/xen/privcmd.c | 4 +- > > drivers/xen/unpopulated-alloc.c | 185 +++++++++++++++++++++= +++ > > drivers/xen/xenbus/xenbus_client.c | 6 +- > > drivers/xen/xlate_mmu.c | 4 +- > > include/xen/xen.h | 9 ++ > > 10 files changed, 215 insertions(+), 15 deletions(-) > > create mode 100644 drivers/xen/unpopulated-alloc.c > >=20 > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > > index 1d339ef92422..018020b91baa 100644 > > --- a/drivers/xen/Kconfig > > +++ b/drivers/xen/Kconfig > > @@ -327,4 +327,8 @@ config XEN_HAVE_VPMU > > config XEN_FRONT_PGDIR_SHBUF > > tristate > > +config XEN_UNPOPULATED_ALLOC > > + bool > > + default y if ZONE_DEVICE && !ARM && !ARM64 >=20 > There is a current effort to enable Xen on RISC-V. Do we expect this > option to be usable for this architecture? It will depend on whether the Xen RISC-V implementation mandates an IOMMU, for example Arm doesn't and hence uses an identity p2m for dom0. If RISC-V does the same then I would assume this won't be suitable as-is (not that it couldn't be made to work). IMO it wasn't clear from the community call what was the RISC-V port position regarding this, but IIRC the IOMMU spec for RISC-V was behind the virtualization one, so it's likely that quite a lot of hardware will have hardware virtualization support but no IOMMU, in which case I think it's likely the RISC-V port will follow Arm and implement an identity p2m. > If yes, I'm fine with the > exclusion of Arm, otherwise I'd opt for defaulting to yes only for > X86. >=20 > Either way you can have my: >=20 > Reviewed-by: Juergen Gross Thanks. Feel free to change the 'ZONE_DEVICE && !ARM && !ARM64' to 'ZONE_DEVICE && X86' if you think it's safer. Roger.