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:c0b::233; helo=mail-it0-x233.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 45F6A21A04E2F for ; Fri, 1 Dec 2017 09:34:05 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id t1so3288723ite.5 for ; Fri, 01 Dec 2017 09:38:31 -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=/FroKaFBKBrpXBSFfxYcEeLFVbB+oTj1qAcO8MixRIk=; b=YB1aLQLmGg6Jm3C2pe/+yY8+xWkxXarivQcYYXnABAQX282Z7LPcyKy1aPxWb5AcTz KrQPnzjSPveP4ral5aShnOdwim5RdJEk1Qm3dk4SPrZ6zXgmegfF/rJMJC1D1C+Km36W A+7J9vY+EttCsYggxXDuWxCe7lXGpFAk76i18= 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=/FroKaFBKBrpXBSFfxYcEeLFVbB+oTj1qAcO8MixRIk=; b=TlTr53GQrQVzNB7rZmE1VXs7nFFTbLe4LHJkgv02N62lKshRb1NihkbcY6gttu4UlE qL18FMCM/cUrII1qUat8nSQQY6WLfCUXzgmby4RmHRSIUXKwIm8Vo+F2iRS+QACxzGTG XjMCZrRPaMPgS854BtsES9Kxr+ReYT+wGZeqDyxPMpiY39VRN+porYtFgCENFwwJkLty Xw1xVt+TtLTAQq0V7hpk0FueyJhjIEKRuJyx+FEyT2TBxgbAZenDRlNUSr3AtJjSk1OM c6B34YQbtCHHzsXggUTFIHwPIe6tueQj4jPmdjBpE27oS7X+Cy/p2l/hKsS7kf0XOqx2 U/VQ== X-Gm-Message-State: AKGB3mLoihXCszy9JVjAX/33Qd2YmiiEseKshfQFEeq2dTH9pRqm+JWI BgJxW9eDKu6JzG5hcagossqLL4jVubXeDbYa+HLOyD9k X-Google-Smtp-Source: AGs4zMa28VEAy8nRLr+zPoJNvwH5zQFOHO+viRzSBiJ1ljzuX0Ywf4WcH9z/Gw6ZkCNuBwV5+f64bAkTS1zBoAAJUEg= X-Received: by 10.36.31.212 with SMTP id d203mr2776914itd.48.1512149911267; Fri, 01 Dec 2017 09:38:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Fri, 1 Dec 2017 09:38:30 -0800 (PST) In-Reply-To: References: <20170926201529.11644-1-evan.lloyd@arm.com> <20170926201529.11644-19-evan.lloyd@arm.com> From: Ard Biesheuvel Date: Fri, 1 Dec 2017 17:38:30 +0000 Message-ID: To: Evan Lloyd Cc: "edk2-devel@lists.01.org" , "ard.biesheuvel@linaro.org@arm.com" <"ard.biesheuvel@linaro.org"@arm.com>, "leif.lindholm@linaro.org@arm.com" <"leif.lindholm@linaro.org"@arm.com>, "Matteo.Carlini@arm.com@arm.com" <"Matteo.Carlini@arm.com"@arm.com>, "nd@arm.com@arm.com" <"nd@arm.com"@arm.com> Subject: Re: [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at build X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:34:05 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 1 December 2017 at 16:56, Evan Lloyd wrote: > Responses inline > >> -----Original Message----- >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >> Sent: 25 October 2017 19:10 >> To: Evan Lloyd >> Cc: edk2-devel@lists.01.org; "ard.biesheuvel@linaro.org"@arm.com; >> "leif.lindholm@linaro.org"@arm.com; >> "Matteo.Carlini@arm.com"@arm.com; "nd@arm.com"@arm.com >> Subject: Re: [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at >> build >> >> On 26 September 2017 at 21:15, wrote: >> > From: Girish Pathak >> > >> > Currently frame buffer memory is either reserved in special VRAM or >> > dynamically allocated using boot services memory allocation functions. >> > When allocated using boot services calls the memory has to be >> > allocated as EfiBootServicesData. Unfortunately failures have been >> > seen with this case. There is also an unfortunate lack of control on >> > the placement of the frmae buffer. >> > >> > This change introduces two PCDs, PcdArmLcdFrameBufferBase and >> > PcdArmLcdFrameBufferSize which enable build time reservation of the >> > frame buffer, avoiding the need to allocate dynamically. This allows >> > the frame buffer to appear as "I/O memory" outside of the normal RAM >> > map, which is similar to the "VRAM" case. >> > >> > This change has no impact on current code, only enables the option of >> > build time reservation of frame buffers. >> > >> >> Where is the memory actually being reserved? And if it is reserved, how = can >> the OS reclaim it if it is not interested in using the GOP? > > [[Evan Lloyd]] The memory is reserved by whatever sets the Pcd - normally= the .dsc. It may or may not be system RAM. > If it is excised from system memory, then there is no way for the OS to r= eclaim it, as it can't differentiate that from the VRAM case. > I'm not sure I see the relevance of that anyway. Is our objective to pro= vide restricted firmware tightly tuned for a specific operating system in a= n unrealistic mode, or to provide a generic example of firmware exercising = the standard interfaces and testing real use cases? > Is that intended as a rhetorical question? If you introduce a feature that may take away RAM from the OS without a way to reclaim it, that deserves a comment. At the very least, it would have saved me from having to ask about it specifically. Whether doing so is justified is another question, but that depends on the expected users of this code (hence the need to document it) --=20 Ard.