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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 31B02C433E1 for ; Tue, 28 Jul 2020 17:44:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EE53C20672 for ; Tue, 28 Jul 2020 17:44:38 +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="KKn7AIpz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE53C20672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none 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 76EFE8D000B; Tue, 28 Jul 2020 13:44:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 720968D0002; Tue, 28 Jul 2020 13:44:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60FFB8D000B; Tue, 28 Jul 2020 13:44:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 4CE638D0002 for ; Tue, 28 Jul 2020 13:44:38 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0BA161EE6 for ; Tue, 28 Jul 2020 17:44:38 +0000 (UTC) X-FDA: 77088209436.28.jelly03_4b0243026f6b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id CB0B06C1A for ; Tue, 28 Jul 2020 17:44:37 +0000 (UTC) X-HE-Tag: jelly03_4b0243026f6b X-Filterd-Recvd-Size: 5663 Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 17:44:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1595958277; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=eHsq7Ta01QmeqnE9DLs8/mBiesJkCYGnL9YfXoA2X4o=; b=KKn7AIpzPAa/9qfIVEM7GpEh9rgcG2VYpLnOt8H1tT06LEN3WpG+km6c 3GurGV5zjD+uoyzC3NQ89Ubic6xMLkVKN9sXfs7F5ZXFcEjlYuadgODGX Jk8n0Si+YH2xZSaTv3Axa28bRHsAtlMbbZHnxidxDITV2FAzwK9RdEbqo s=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 2RdrO/AnzZYrb9zj19qTPY0bAooeEOHP1ELFiUghgXaTqNYu/IsfAaeOofDt0adaNBw2Xa0AC6 t6lHyuGC5gkUWy/N7rzG8yB31qUpk6aKp4puI4SGJ8w7qoXEtqg8F+J/doKRdiBkCkcVvIxcwR q9J9cBAZhRCwaqR6vQaMZgUwvDwO9y4NebuTt/KmXt2MRQWqepK8FGyJefexjYCWZrVGObAaI8 Yw/nTGNLt85irvc409hapDt3JL5ro6jwcrTY4qUVugZVoEP/hHQ79mpfhww2W8LLw7sXFLWMwl r/U= X-SBRS: 2.7 X-MesageID: 23704211 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,406,1589256000"; d="scan'208";a="23704211" Date: Tue, 28 Jul 2020 19:44:29 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall CC: , Juergen Gross , "Stefano Stabellini" , Wei Liu , "Oleksandr Andrushchenko" , David Airlie , Yan Yankovskyi , David Hildenbrand , , Michal Hocko , , Daniel Vetter , , Boris Ostrovsky , Dan Williams , "Dan Carpenter" Subject: Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory Message-ID: <20200728174429.GC7191@Air-de-Roger> References: <20200727091342.52325-1-roger.pau@citrix.com> <20200727091342.52325-5-roger.pau@citrix.com> <20200728165919.GA7191@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-Rspamd-Queue-Id: CB0B06C1A X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Tue, Jul 28, 2020 at 06:12:46PM +0100, Julien Grall wrote: > Hi Roger, >=20 > On 28/07/2020 17:59, Roger Pau Monn=C3=A9 wrote: > > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote: > > > Hi, > > >=20 > > > On 27/07/2020 10:13, 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 i= n > > > > order to create struct pages and kernel virtual mappings for the = IOMEM > > > > 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-pl= ace > > > > replacement of the callers. Once a memory region has been added t= o be > > > > used as scratch mapping space it will no longer be released, and = pages > > > > returned are kept in a linked list. This allows to have a buffer = of > > > > pages and prevents resorting to frequent additions and removals o= f > > > > regions. > > > >=20 > > > > If enabled (because ZONE_DEVICE is supported) the usage of the ne= w > > > > functionality untangles Xen balloon and RAM hotplug from the usag= e of > > > > unpopulated physical memory ranges to map foreign pages, which is= the > > > > correct thing to do in order to avoid mappings of foreign pages d= epend > > > > on memory hotplug. > > > I think this is going to break Dom0 on Arm if the kernel has been b= uilt with > > > hotplug. This is because you may end up to re-use region that will = be used > > > for the 1:1 mapping of a foreign map. > > >=20 > > > Note that I don't know whether hotplug has been tested on Xen on Ar= m yet. So > > > it might be possible to be already broken. > > >=20 > > > Meanwhile, my suggestion would be to make the use of hotplug in the= balloon > > > code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)? > >=20 > > Right, this feature (allocation of unpopulated memory separated from > > the balloon driver) is currently gated on CONFIG_ZONE_DEVICE, which I > > think could be used on Arm. > >=20 > > IMO the right solution seems to be to subtract the physical memory > > regions that can be used for the identity mappings of foreign pages > > (all RAM on the system AFAICT) from iomem_resource, as that would mak= e > > this and the memory hotplug done in the balloon driver safe? >=20 > Dom0 doesn't know the regions used for the identity mappings as this is= only > managed by Xen. So there is nothing you can really do here. OK, I will add the guards to prevent this being built on Arm. > But don't you have the same issue on x86 with "magic pages"? Those are marked as reserved on the memory map, and hence I would expect them to never end up in iomem_resource. Thanks, Roger.