Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp462473ybg; Tue, 28 Jul 2020 10:14:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/zDdyhfDGW2cjqVkD4eeZLlQWkoIvpkO697bmEjwF3jiBGCRrFacvYR7Bd9zHZoQcTqGk X-Received: by 2002:a05:6402:12d7:: with SMTP id k23mr19734027edx.312.1595956485101; Tue, 28 Jul 2020 10:14:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595956485; cv=none; d=google.com; s=arc-20160816; b=QgJO0keuHsM2IjEKm1AMB6Dzj9Smla5925rx+5JdH4PI5w1hgv3GFhLXj9REyazTPf 30RObMXgPu0jOOoOVci4HLj3bUJde5JWwkugBPCmTe0WEDoCIGTpunndt4r4r6e88onj IbvpZJ3lZ41iLBK0uKrTbEzXW8DG7Cvi74r4m6ndYIiCJet9nvcP6JInl/wJbk96eA4b M0Z3Q6XheADuN1bGNyaQG5qcK/lCsuCF/NVpC9fKV23iUvt2b5iPhH/s+vdJ/PYEwyZ5 +mKdUbpChlKUyR5Yk6ZJy0tD+HSKCs+VV4GkXdhDMOqVMMZvuPlW+a825H4gcGEj5kI8 nvSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=gAxUDflyYD2Qz0uZDypM7APCGN6LsjUhjSUSWoYLPcY=; b=gRckDg8FTbtU6abbb+qX7kPy+MwkxfgmiQlwrtNO6KSjeLdWRUKaf9TaSygW4gk+b6 YbZZR6sVlpdwkc/ZCLK13c+ZCugZdEXFOFWc2i+QrXnR4wcD66aF+Ge9LSPR7SRrIaU8 //Xby8ZSuS5qtvMHYjfUH40W6tfTSl5AsBcu5R3OajI1mH/G+cdtB4Zhf7j9I5E+QJ8Z Ufcf/ZPGFnv6JqMPN4OgUkVCmiI5EhyYqJNOr2OdCoHj13zSgujlCJZ3V11nzdbjvtzR AM8MLnInr/ByoDmiHoFWfYvMrbO0xbWUcNyRjnRCjYB490XGMA2BkrauNTlK5c6JyikM NkKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@xen.org header.s=20200302mail header.b=U8RJ5NSw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y9si3493985edm.246.2020.07.28.10.14.21; Tue, 28 Jul 2020 10:14:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@xen.org header.s=20200302mail header.b=U8RJ5NSw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731841AbgG1RNC (ORCPT + 99 others); Tue, 28 Jul 2020 13:13:02 -0400 Received: from mail.xenproject.org ([104.130.215.37]:47072 "EHLO mail.xenproject.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731684AbgG1RNC (ORCPT ); Tue, 28 Jul 2020 13:13:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gAxUDflyYD2Qz0uZDypM7APCGN6LsjUhjSUSWoYLPcY=; b=U8RJ5NSwZQ8iU78q1Zh5y2VxyZ KLqWvDt3ijkmQpa/cyxyk4D4lH1X6HTzXUZ8buyclAQa4oFopGO7GizuG8UlZlYXhKf06aO3+jWxW L5i2sFLebxgLmSaQiTOm/ba8eK8Vj7kcWqyUDl3TI1/IWRsEE2Nm52OaedKFXHgUc09g=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k0T9m-0005gL-AT; Tue, 28 Jul 2020 17:12:50 +0000 Received: from 54-240-197-239.amazon.com ([54.240.197.239] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0T9l-0004gC-Us; Tue, 28 Jul 2020 17:12:50 +0000 Subject: Re: [PATCH v3 4/4] xen: add helpers to allocate unpopulated memory To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: linux-kernel@vger.kernel.org, Juergen Gross , Stefano Stabellini , Wei Liu , Oleksandr Andrushchenko , David Airlie , Yan Yankovskyi , David Hildenbrand , dri-devel@lists.freedesktop.org, Michal Hocko , linux-mm@kvack.org, Daniel Vetter , xen-devel@lists.xenproject.org, 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: Julien Grall Message-ID: Date: Tue, 28 Jul 2020 18:12:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roger, On 28/07/2020 17:59, Roger Pau Monné 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 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. >>> >>> 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 pages >>> 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 depend >>> on memory hotplug. >> I think this is going to break Dom0 on Arm if the kernel has been built 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 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 make > this and the memory hotplug done in the balloon driver safe? 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. But don't you have the same issue on x86 with "magic pages"? Cheers, -- Julien Grall