From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::243; helo=mail-io0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 C5BBC2034863B for ; Tue, 22 May 2018 03:43:17 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id e20-v6so17876213iof.4 for ; Tue, 22 May 2018 03:43:17 -0700 (PDT) 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=ypMHngPVRik9IE6jJLHdRmPEZSCDgYZQbSj9bTlj0X4=; b=TetGhzan6lDK+cDLtOGLY2F3IuogVW6E8OHNZTebjX6mDnWYyeHBW7HZOxOAV/8HhT v1CPfdYXK208SzEXe1kceRq0LJ+9oNeE5fTAeippKwUa0IpcQntqesJQ3gmgY8Ypme9T xHOU1gfJi+oIFKbyw0MjLivPLLOXafe6dk1hg= 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=ypMHngPVRik9IE6jJLHdRmPEZSCDgYZQbSj9bTlj0X4=; b=N7Ylwm25Zmyytel/Yaz2e+ccNC145kzh5XLkIHGkAOmtLX2roYjyHHFcglznaDJOvk 8pF8Vq87gE2S1wS4dqmSXF5ipamXqA5ltVa+6F5e6NihEDL6PVYA3tHqLsWEmCx298HI gtduYDoKXTGqMNpZNZh9aK7AASBHxYLM7FmdSX79izbmQX1ZdB9rFx42jfeP7BaNPVks xN1TGlhM/I81RE/5l94TfelUdFQA15PS+2XUH3NP03D7m+D6f+GMh/qdBNnAHLVHjUMw 3QxJgl5y4eUZiXpMI2cPGYyxp+8YFKrUOG1JcWO1lli0/wsSAC9ibkwBY24pR0EhJf/g f5JA== X-Gm-Message-State: ALKqPwf4WH+yVPq5cJvaByCP0+J+9df+S+EeEFsaUoUwEMDxxoxGWkWv BY8eZPMqPh7sgMdfM6RTyBOEinThhAIiKhBZfitJhQ== X-Google-Smtp-Source: AB8JxZr6QXvYpoa+FjHVY+TMivonRSfpboYsKlJPK5A2VbwSFkZV/AXUHxPDKqk1sS3gZE08ijJffxGwylD5O14dQfo= X-Received: by 2002:a6b:268b:: with SMTP id m133-v6mr26113532iom.107.1526985797036; Tue, 22 May 2018 03:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.187.134 with HTTP; Tue, 22 May 2018 03:43:16 -0700 (PDT) In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE309@shsmsx102.ccr.corp.intel.com> References: <1517320437-11688-1-git-send-email-dandan.bi@intel.com> <1517320437-11688-4-git-send-email-dandan.bi@intel.com> <3C0D5C461C9E904E8F62152F6274C0BB3BAD755F@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE227@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE2BC@shsmsx102.ccr.corp.intel.com> <7e5f817f-d2b9-1359-974c-ace751cd2984@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103BAEE309@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 22 May 2018 12:43:16 +0200 Message-ID: To: "Zeng, Star" Cc: Laszlo Ersek , "Bi, Dandan" , Andrew Fish , "Kinney, Michael D" , Leif Lindholm , "edk2-devel@lists.01.org" , "Gao, Liming" , Matt Sealey Subject: Re: [PATCH v2 3/8] MdeModulePkg/DxeCorePerformanceLib:Track FPDT record in DXE phase X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 10:43:18 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 22 May 2018 at 12:38, Zeng, Star wrote: > I could not recall the whole background. > > Let us separate the problem into two parts. > > 1. For this special case in DxeCorePerformanceLib, we at least have appro= ach (although just for short term). I disagree. The approach involves attempting to allocate below 4 GB, and fall back to allocating elsewhere if that fails. On X64, the fallback should not exist. If the first allocation fails, you will end up with an allocation that PEI may not be able to access, and you will not get any error or warning about this condition. On other architectures, allocating below 4 GB unnecessarily may be wasteful, since it uses up 32-bit addressable that we may prefer to use for DMA, for instance, given that 32-bit DMA is more efficient even on PCIe systems. So even if it makes the error go away, I think it is not a solution at all. > 2. For the general problem about whether introducing new interface (PCD a= nd API, seemingly it needs to be in MdePkg), it depends on whether we agree= to add new interface and seems need more time to discuss. If yes, then lib= rary/driver could be updated to consume it. > > If we agree to add new interface, as current instances of MemoryAllocatio= nLib are very nature by phases (PEI, DXE (Uefi/DxeCore), SMM, etc), but the= new interface is just needed in DXE (Uefi/DxeCore) instances, how about ad= ding it in UefiLib? > That is a good point, actually. I will look into this.