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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 2D4F4C2BA19 for ; Wed, 15 Apr 2020 13:24:44 +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 EB49820737 for ; Wed, 15 Apr 2020 13:24:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=xen.org header.i=@xen.org header.b="nWKrSyL/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB49820737 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jOi1Y-0003C8-Tj; Wed, 15 Apr 2020 13:24:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jOi1X-0003C3-Ft for xen-devel@lists.xenproject.org; Wed, 15 Apr 2020 13:24:15 +0000 X-Inumbo-ID: 66c9ffe8-7f1c-11ea-9e09-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 66c9ffe8-7f1c-11ea-9e09-bc764e2007e4; Wed, 15 Apr 2020 13:24:15 +0000 (UTC) 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=8pNF50j22WVox24Z159EB27HGmrQcEzMaNofE2TuaEA=; b=nWKrSyL/lSjBOeSmFCPDPxJB3w S0QxVlkr80dAwx6xVfekidJneje5edYgfS6c1CqiGtD97PyDJCnBgnT5zxqHcgUrETdPcdoQIBUp7 EknnK5fffybbFnib9PGh5wuWfNjJR1Zv/Ubuof8jBRuYjtAYCWjDmas6oF3c0fU+BS44=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jOi1R-0003jy-Vy; Wed, 15 Apr 2020 13:24:09 +0000 Received: from [54.239.6.177] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1jOi1R-0006ZR-N5; Wed, 15 Apr 2020 13:24:09 +0000 Subject: Re: [PATCH 05/12] xen: introduce reserve_heap_pages To: Stefano Stabellini , xen-devel@lists.xenproject.org References: <20200415010255.10081-5-sstabellini@kernel.org> From: Julien Grall Message-ID: Date: Wed, 15 Apr 2020 14:24:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200415010255.10081-5-sstabellini@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , andrew.cooper3@citrix.com, Ian Jackson , George Dunlap , jbeulich@suse.com, Stefano Stabellini , Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/04/2020 02:02, Stefano Stabellini wrote: > Introduce a function named reserve_heap_pages (similar to > alloc_heap_pages) that allocates a requested memory range. Call > __alloc_heap_pages for the implementation. > > Change __alloc_heap_pages so that the original page doesn't get > modified, giving back unneeded memory top to bottom rather than bottom > to top. > > Also introduce a function named reserve_domheap_pages, similar to > alloc_domheap_pages, that checks memflags before calling > reserve_heap_pages. It also assign_pages to the domain on success. Xen may have already allocated the part of region for its own purpose or for another domain. So this will not work reliably. We have the same issues with LiveUpdate as memory have to be preserved. We need to mark the page reserved before any allocation (including early boot allocation) so nobody can use them. See [1]. Cheers, [1] Live update: boot memory management, data stream handling, record format -- Julien Grall