From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 149BF821FA for ; Fri, 3 Mar 2017 01:12:23 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id 203so9200201ith.0 for ; Fri, 03 Mar 2017 01:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CtPOIDM3Dru5e1QR0TRx4vJw0amoSfcRCOiA1GKIEr8=; b=EaETuDQqORzKFmjY0X6ILJ3a+olhPg0cP5bLTtqDRCFfNLzVEzu6GC1LpxI50zPfXu /h2AX2YCl9DMQbsRfXNfxf3f0/w+426hKli3HJDV1OqWPJjPXybwOpyXrLo4G2td3993 ZP8FS12BNnPezHQxlUu4684omJdAz0n1EoZ4g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CtPOIDM3Dru5e1QR0TRx4vJw0amoSfcRCOiA1GKIEr8=; b=TCaFcgV00GySW/rkqEcv4nUyCGXrj4MlsfPFNL9ZEsB2t4S0TZbY6FKBDPuGUEryPD M3+XN47B4mGsqQyRGG6sYezy6C3wqrEvwbz8uOHtCNoY7r5gMIvMkP3ihyFQCxww2eQM GdkF3S6LEgv92DfAP19cSJZxLdSVbCI/zaC52HSvYTEbkdBH8UBMFS+ITyUUTVCzt3Dl AVhsmWPp7C3j74tixTdySIgVobs2j/jIwPGTu/yXVdA1LejHyqxsD/bSo86UMjLCBtCo KkQtpBQAPT+6P9M/3pOy+KcsTvbqDCmT3htyJUq0WSWeg4ub4//9cPa6VqqZ5gAJnG66 zH2Q== X-Gm-Message-State: AMke39n5ht1PEq/nuUYLntWusLtGRrWZAt19+u6vPqJsOKoyAIn3u+XImhBMSu0FinxUrb37wjfHCQkfSM2ASpoL X-Received: by 10.36.118.68 with SMTP id z65mr2247775itb.59.1488532342347; Fri, 03 Mar 2017 01:12:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Fri, 3 Mar 2017 01:12:21 -0800 (PST) In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D6E7A69@shsmsx102.ccr.corp.intel.com> References: <1488530263-22906-1-git-send-email-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A14D6E7A69@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 3 Mar 2017 09:12:21 +0000 Message-ID: To: "Gao, Liming" Cc: "edk2-devel@lists.01.org" , "Zeng, Star" Subject: Re: [PATCH v2] MdeModulePkg/PeiCore: honour minimal runtime allocation granularity X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:12:23 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 March 2017 at 09:05, Gao, Liming wrote: > Ard: > First is to make FreeMemoryTop at the expected alignment. If original F= reeMemoryTop is not aligned, it will be adjusted to be align. Then, there i= s one memory hole that can't be used any more. I suggest to create BuildMem= oryAllocationHob() with EfiConventionalMemory to describe this hole. OK. But the original code may already result in some non-page aligned memory to be discarded, should that be described as well? Or should the EfiConventionalMemory HOB cover full pages only? Now, MdePkg\Library\PeiMemoryAllocationLib AllocateAlignedPages() uses this way to describe extra memory space. Thanks, Ard.