From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 EE39B21E945F2 for ; Sun, 17 Sep 2017 21:27:42 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id w94so15725047ioi.7 for ; Sun, 17 Sep 2017 21:30:46 -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; bh=zyC28ErvG4ripmZDVxWFLUwToeNFGZBdZ1ocAm0DgTI=; b=agGcSNjeSL6LorgqIZ6E4vYkbKqVrAlznLnDANkrm+mZSrOf6NYajkX6h1ONQ7kjo+ DWs75YvNAQ45ozyn1rfTArynwAisyP1lmIjp698KmtuZoQuc32nJFAFgEhLSOoJyyH1I ntCrtfLhQgrLbYKZ+u/90ys9xoBg5KiGCsU+8= 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; bh=zyC28ErvG4ripmZDVxWFLUwToeNFGZBdZ1ocAm0DgTI=; b=TK7Lbe2+G5C16AnujjM7wQoGTM6knN1U4Uw0AUxNbFKxvfY6nf1N8KqF25zkBlZmDH jq/UqaiJ6qONsyLAoYV8GPPxsIEdgcBOG6dLDqDSkhVIKVl+g4BGwhAQVCkiwMBL/1Su CWQ8hy5VgtWUBNifSaBylUFbXeDf3uNZYt9azoq0FsTrjAglhOK/5jkrMpwiywM4KZdQ s/yav9adndgTvo0drO6ULOOtL10ib9GPXSA2auZv5t7vDEoxncl5JKZCaAvSQnEU14Pb oQzW64M9zqYOIMuRaZ2wdNt9xIXSEkdGWzdRZe5GMY6t0130PyQBjL355BppS8Bz9oJw Qu9Q== X-Gm-Message-State: AHPjjUh2vos9PJIbg1OaZg6qi+xqE25+QBAFiMlgJIAC6ij0Q2QWUSF1 OLjsU9RTX8wiZvQdqsogytA2buMQ1dOLmZpzNN6e3w== X-Google-Smtp-Source: AOwi7QAZDUPcpSBSgUd9L77oYn44Ev7u1zvbi50RTKPj/02FGrnUmp67FzE537+rPBwLPAxfWafxdGaQdY9pG3xvWm4= X-Received: by 10.107.43.69 with SMTP id r66mr16724966ior.2.1505709045442; Sun, 17 Sep 2017 21:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.18 with HTTP; Sun, 17 Sep 2017 21:30:44 -0700 (PDT) In-Reply-To: References: <1505485954-24345-1-git-send-email-meenakshi.aggarwal@nxp.com> <20170915101338.agohuaoakeaokevb@bivouac.eciton.net> From: Ard Biesheuvel Date: Sun, 17 Sep 2017 21:30:44 -0700 Message-ID: To: Udit Kumar Cc: Leif Lindholm , "edk2-devel@lists.01.org" Subject: Re: [PATCH] RFC Inform UEFI memory to Linux 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: Mon, 18 Sep 2017 04:27:43 -0000 Content-Type: text/plain; charset="UTF-8" On 17 September 2017 at 21:07, Udit Kumar wrote: > Hi Ard, > >> Thanks for the patch. But please consider carefully what you're doing: >> My point is really that you can just remove lines 124 - 189 instead. > > We want, OS to re-use firmware volume area. Therefore making firmware volume visible. > You are right, removing lines 124-189 will do the same, and no need of adding splitting area with same > attribute. > > Also, I am not sure, if we can remove this entirely, therefore we posted this as RFC:) > Code comments says > > // EDK2 does not have the concept of boot firmware copied into DRAM. To avoid the DXE > // core to overwrite this area we must mark the region with the attribute non-present > > On our architecture, we start boot from DRAM. And we haven't seen any overwrite > by DXE. This work perfectly well for us. > > Do you think, on other platforms it may add a risk of overwrite ? > We wondered about that as well. As far as I can tell, a compressed FV will be decompressed completely into a memory region that is reserved for it before the DXE core is invoked. This means the outer, uncompressed FV could technically be overwritten, but in practice, we never refer back to it in a PrePi build, and we should probably not even build the FV hob for this volume if we can avoid it.