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 550FFC433E1 for ; Tue, 28 Jul 2020 17:42:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 191CD20672 for ; Tue, 28 Jul 2020 17:42: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="Isvlt8g6" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 191CD20672 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 A2E728D0006; Tue, 28 Jul 2020 13:42:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B8CF8D0002; Tue, 28 Jul 2020 13:42:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 880608D0006; Tue, 28 Jul 2020 13:42:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 6EE718D0002 for ; Tue, 28 Jul 2020 13:42:52 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 289BC180AD815 for ; Tue, 28 Jul 2020 17:42:52 +0000 (UTC) X-FDA: 77088204984.14.pear04_2a04ffe26f6b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id F0A541822987A for ; Tue, 28 Jul 2020 17:42:51 +0000 (UTC) X-HE-Tag: pear04_2a04ffe26f6b X-Filterd-Recvd-Size: 6255 Received: from esa3.hc3370-68.iphmx.com (esa3.hc3370-68.iphmx.com [216.71.145.155]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 17:42:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1595958172; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=bm6xpS3UPlSHgrr/AwBHxbllr8iQgva7zYaEqmfywQE=; b=Isvlt8g6tTyBuPgT6CzTYbpm21V5W2Qq0D78W3YuJnZTzZvyM4MLtigM 92A2YgHALjRR9DT0V2nHkaxuWsIbgD2l1OuNmgFfhJbWeRuL/ZyD4tGSU NSEaH1ZCxWuEOkbFAYJ/LETnb6RZeE10gXtXtmiJMTYDDxrxbrtbZlhxg c=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tqfc4/1PrubWMv5ewSP0LHdTujHFP8U+m86/9kdKUf1uh2GxSqdRLKvvIjL7M7hl/BUVdvDraQ 7xWgR+boyI9h5kdqmKdL4Un2zB12iUpSymGIbUEEQ7O8Hw5Bf2EayFOnHW8bDGV9iixxNVgLOC ohHW/uZUKSlMasSdB5PVjkQ2CjgPz8+aAB4j7j0KQdWkgHS/AF8C2gxIr9YIlD7LejhmX4/3f6 NuNWHo6AupAExmeZCKgns9LBWBBDJcckRANyYzThzC0R8PZACty0nlqgJXI7DofDVY/yjkEeEd sT0= X-SBRS: 2.7 X-MesageID: 23367204 X-Ironport-Server: esa3.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="23367204" Date: Tue, 28 Jul 2020 19:42:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper CC: Julien Grall , 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: <20200728174242.GB7191@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: F0A541822987A 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 Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote: > 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, > >> > >> On 27/07/2020 10:13, Roger Pau Monne wrote: > >>> To be used in order to create foreign mappings. This is based on th= e > >>> ZONE_DEVICE facility which is used by persistent memory devices in > >>> order to create struct pages and kernel virtual mappings for the IO= MEM > >>> 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. > >>> > >>> The newly added helpers use the same parameters as the existing > >>> {alloc/free}_xenballooned_pages functions, which allows for in-plac= e > >>> 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 pa= ges > >>> 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. > >>> > >>> 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 t= he > >>> correct thing to do in order to avoid mappings of foreign pages dep= end > >>> on memory hotplug. > >> I think this is going to break Dom0 on Arm if the kernel has been bu= ilt with > >> hotplug. This is because you may end up to re-use region that will b= e used > >> for the 1:1 mapping of a foreign map. > >> > >> Note that I don't know whether hotplug has been tested on Xen on Arm= yet. So > >> it might be possible to be already broken. > >> > >> Meanwhile, my suggestion would be to make the use of hotplug in the = balloon > >> code conditional (maybe using CONFIG_ARM64 and CONFIG_ARM)? > > 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. > > > > 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 > The right solution is a mechanism for translated guests to query Xen to > find regions of guest physical address space which are unused, and can > be safely be used for foreign/grant/other=C2=A0 mappings. >=20 > Please don't waste any more time applying more duct tape to a broken > system, and instead spend the time organising some proper foundations. The piece added here (using ZONE_DEVICE) will be relevant when Xen can provide the space to map foreign pages, it's just that right now it relies on iomem_resource instead of a Xen specific resource map that should be provided by the hypervisor. It should indeed be fixed, but right now this patch should allow a PVH dom0 to work slightly better. When Xen provides such areas Linux just needs to populate a custom Xen resource with them and use it instead of iomem_resurce. The Arm stuff I'm certainly not familiar with, and can't provide much insight on that. If it's best to just disable it and continue to rely on ballooned out pages that's fine. Roger.