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=-6.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 DE420C433EA for ; Tue, 28 Jul 2020 17:06:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A209C20786 for ; Tue, 28 Jul 2020 17:06:36 +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="O8Dr5+wf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A209C20786 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 3D4576B0006; Tue, 28 Jul 2020 13:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3851A8D0002; Tue, 28 Jul 2020 13:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2737A6B0022; Tue, 28 Jul 2020 13:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 0DD406B0006 for ; Tue, 28 Jul 2020 13:06:36 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B9B418248D51 for ; Tue, 28 Jul 2020 17:06:35 +0000 (UTC) X-FDA: 77088113550.11.loaf87_201824326f6b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id B2230180F8BA9 for ; Tue, 28 Jul 2020 17:06:32 +0000 (UTC) X-HE-Tag: loaf87_201824326f6b X-Filterd-Recvd-Size: 5472 Received: from esa6.hc3370-68.iphmx.com (esa6.hc3370-68.iphmx.com [216.71.155.175]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 17:06:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1595955991; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NhQlpfgEzw5uIL26d7//uQgtQ8+lTO6nNMY87duUokQ=; b=O8Dr5+wflPoHgMNwSG90Lkw7PM5DuRN7DSm/wfSus+sfwGGQ8VnhCxFJ LGZDWWAx0qEdA2lsYcePWzpQ7m4oOMqHHwMBCjsZOkuhOa/aQqBvCu9eN gAY/ttoVvjtTnNswb4DIHtVbycRPlVcEV+VEJLRPp+Hnyzc2wl46VHTwQ Q=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Zv07BbGuPhsiZuK1RAL+MXQS7+DkALPbSOLVSZU6zFhcWsNovWd2ezPA0u0r1ydAx+ftO+5rIq NYZIB7Ir83eaSN5NLUnEQUwpkSM93rbTHf5FdDjDIWKAeHW5XlIoRUumb0e9wguAvIvp4K7b+H wj1PKHL59HxgJHNABW9nSYRmjho8ubni3kkx1ZFgHlasMw2iQH4TLZsXntv6C0nojnpI0osC1H P4GfMlvA6ODgHDaodR3qUiDDbVxaEHvhgheUl2K9TujfOtvBGncUzSfPj+3oWbSEcATqj0RXdv ExM= X-SBRS: 2.7 X-MesageID: 23700460 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="23700460" Subject: Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , 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" References: <20200727091342.52325-1-roger.pau@citrix.com> <20200727091342.52325-5-roger.pau@citrix.com> <20200728165919.GA7191@Air-de-Roger> From: Andrew Cooper Message-ID: Date: Tue, 28 Jul 2020 18:06:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200728165919.GA7191@Air-de-Roger> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-Rspamd-Queue-Id: B2230180F8BA9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 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 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. >>> >>> 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. >>> >>> 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. >> I think this is going to break Dom0 on Arm if the kernel has been buil= t 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. >> >> Note that I don't know whether hotplug has been tested on Xen on Arm y= et. So >> it might be possible to be already broken. >> >> Meanwhile, my suggestion would be to make the use of hotplug in the ba= lloon >> 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 make > this and the memory hotplug done in the balloon driver safe? 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. Please don't waste any more time applying more duct tape to a broken system, and instead spend the time organising some proper foundations. ~Andrew