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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D64AAC433F5 for ; Mon, 4 Oct 2021 06:42:40 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 88D406139F for ; Mon, 4 Oct 2021 06:42:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 88D406139F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.201194.355617 (Exim 4.92) (envelope-from ) id 1mXHfh-0008Vd-VW; Mon, 04 Oct 2021 06:41:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 201194.355617; Mon, 04 Oct 2021 06:41:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mXHfh-0008VW-Sd; Mon, 04 Oct 2021 06:41:57 +0000 Received: by outflank-mailman (input) for mailman id 201194; Mon, 04 Oct 2021 06:41:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mXHfg-0008VP-52 for xen-devel@lists.xenproject.org; Mon, 04 Oct 2021 06:41:56 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mXHfd-0005Oi-PE; Mon, 04 Oct 2021 06:41:53 +0000 Received: from laubervilliers-658-1-38-51.w217-128.abo.wanadoo.fr ([217.128.182.51] helo=[192.168.84.62]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mXHfd-0005KO-FW; Mon, 04 Oct 2021 06:41:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=VZzRJ1f0EbcrV3t9fSr9jAh3C0eP9022KE2MRf/+xsY=; b=OOYslnTDL0Ap4MtGfIGQ2KkRw4 bazfo8m/wcIN842DecSNBPH6gvAVkgnzPN4kL9LRRDS+naI5HbCg6kdl/2MN05J40VayN5o3oPJOf sO7DvZ403k92WL0D6UTFXsoSzb5AUtNEEsmt4YPSt2bcG2T4fUcCwyoV3YBDdaiz5CDQ=; Message-ID: Date: Mon, 4 Oct 2021 08:41:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCH V4 2/3] xen/arm: Add handling of extended regions for Dom0 To: Stefano Stabellini , Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, Oleksandr Tyshchenko , Andrew Cooper , George Dunlap , Ian Jackson , Jan Beulich , Wei Liu , Volodymyr Babchuk References: <1632955927-27911-1-git-send-email-olekstysh@gmail.com> <1632955927-27911-3-git-send-email-olekstysh@gmail.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Stefano, On 02/10/2021 02:33, Stefano Stabellini wrote: > On Thu, 30 Sep 2021, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko >> >> The extended region (safe range) is a region of guest physical >> address space which is unused and could be safely used to create >> grant/foreign mappings instead of wasting real RAM pages from >> the domain memory for establishing these mappings. >> >> The extended regions are chosen at the domain creation time and >> advertised to it via "reg" property under hypervisor node in >> the guest device-tree. As region 0 is reserved for grant table >> space (always present), the indexes for extended regions are 1...N. >> If extended regions could not be allocated for some reason, >> Xen doesn't fail and behaves as usual, so only inserts region 0. >> >> Please note the following limitations: >> - The extended region feature is only supported for 64-bit domain >> currently. >> - The ACPI case is not covered. >> >> *** >> >> As Dom0 is direct mapped domain on Arm (e.g. MFN == GFN) >> the algorithm to choose extended regions for it is different >> in comparison with the algorithm for non-direct mapped DomU. >> What is more, that extended regions should be chosen differently >> whether IOMMU is enabled or not. >> >> Provide RAM not assigned to Dom0 if IOMMU is disabled or memory >> holes found in host device-tree if otherwise. Make sure that >> extended regions are 2MB-aligned and located within maximum possible >> addressable physical memory range. The minimum size of extended >> region is 64MB. The maximum number of extended regions is 128, >> which is an artificial limit to minimize code changes (we reuse >> struct meminfo to describe extended regions, so there are an array >> field for 128 elements). >> >> It worth mentioning that unallocated memory solution (when the IOMMU >> is disabled) will work safely until Dom0 is able to allocate memory >> outside of the original range. >> >> Also introduce command line option to be able to globally enable or >> disable support for extended regions for Dom0 (enabled by default). >> >> Suggested-by: Julien Grall >> Signed-off-by: Oleksandr Tyshchenko > > I thought about it and I decided to commit this patch because it doesn't > actually need anything from the other two patches, and it is very useful > on its own (both of them are for domU, while this one is for dom0). > > In regards to Julien's suggestion: as explained in earlier emails I > prefer this version but I don't have a strong opinion. If Julien still > prefers the other approach we can still change it in time for 4.16 > (Oleksandr has already implemented both and I am happy to review.) Lets keep the committed approach for the 4.16. This is not something we tie into the ABI so it can be modified later on if we find some issues (i.e. more and more ranges to exclude). However, I would still like to see some changes on top of this patch for 4.16 (will comment separately). Cheers, -- Julien Grall