public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
To: Sakar Arora <Sakar.Arora@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>
Subject: Re: [PATCH v2] PeiLib : Inform UEFI memory to Linux
Date: Mon, 25 Sep 2017 05:47:20 +0000	[thread overview]
Message-ID: <DB5PR04MB09986AE816072941F9AA98EE8E7A0@DB5PR04MB0998.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <DB6PR08MB26450234CE8B24D7795FF25EE0610@DB6PR08MB2645.eurprd08.prod.outlook.com>

Hi All,


Please review the patch and share your comments.


Thanks,
Meenakshi

> -----Original Message-----
> From: Sakar Arora [mailto:Sakar.Arora@arm.com]
> Sent: Wednesday, September 20, 2017 1:50 PM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>; edk2-
> devel@lists.01.org; leif.lindholm@linaro.org
> Subject: RE: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> Thanks for the information. Seems my understanding was not correct in this
> context. I have no other doubts on this change.
> 
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Wednesday, September 20, 2017 12:02 PM
> To: Sakar Arora <Sakar.Arora@arm.com>
> Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>; edk2-
> devel@lists.01.org; leif.lindholm@linaro.org
> Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> 
> On 19 September 2017 at 22:32, Sakar Arora <Sakar.Arora@arm.com> wrote:
> > The DXE core dispatcher relies on the available memory to allocate space
> for loading the rest of the modules from the UEFI image. If we declare the
> UEFI image memory space (from which DXE dispatcher reads the efi
> modules) open to allocation, it might lead to data corruption, depending on
> the location of UEFI image and cumulative size of uncompressed EFI
> modules.
> >
> > Also, since UEFI allows unloading and loading of drivers at runtime, IMO,
> there is a need to preserve the UEFI image even after all the modules have
> been decompressed and loaded in the boot sequence.
> >
> 
> None of this is relevant. The uncompressed firmware volume containing DXE
> core and everything else is preserved as before. The only thing that gets
> discarded is the outer FV, which only contains the PrePi SEC module, and the
> compressed FV, neither of which is ever touched again after DXE core has
> started executing. So we should not register the FV in the first place, and not
> reserve the memory so we don't lose it.
> 
> If you still think this may break anything, could you please elaborate?
> 
> 
> 
> > -----Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > Sent: Tuesday, September 19, 2017 6:18 PM
> > To: Sakar Arora <Sakar.Arora@arm.com>
> > Cc: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>;
> > edk2-devel@lists.01.org; leif.lindholm@linaro.org
> > Subject: Re: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >
> > On 19 September 2017 at 01:07, Sakar Arora <Sakar.Arora@arm.com>
> wrote:
> >> This change will create the possibility for memory space holding the UEFI
> image to be over-written by the DXE core code, since this space will then be
> available for allocation.
> >
> > Yes. But why does this matter after the entire payload has been
> decompressed into memory already?
> >
> >
> >> Any such change, if required, should be done just before booting the OS.
> >>
> >> -----Original Message-----
> >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> >> Of Meenakshi Aggarwal
> >> Sent: Tuesday, September 19, 2017 6:02 PM
> >> To: edk2-devel@lists.01.org; leif.lindholm@linaro.org;
> >> ard.biesheuvel@linaro.org
> >> Subject: [edk2] [PATCH v2] PeiLib : Inform UEFI memory to Linux
> >>
> >> While creating Hob list, ArmPlatformPkg is hiding UEFI memory.
> >> whereas this memory can be used by OS.
> >>
> >> This patch, allows OS to use UEFI code area.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> >> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> >> ---
> >>  ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c | 69
> >> -------------------------
> >>  1 file changed, 69 deletions(-)
> >>
> >> diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> index 2feb11f..d03214b 100644
> >> --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> +++ b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.c
> >> @@ -70,11 +70,7 @@ MemoryPeim (
> >>  {
> >>    ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
> >>    EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
> >> -  UINT64                       ResourceLength;
> >>    EFI_PEI_HOB_POINTERS         NextHob;
> >> -  EFI_PHYSICAL_ADDRESS         FdTop;
> >> -  EFI_PHYSICAL_ADDRESS         SystemMemoryTop;
> >> -  EFI_PHYSICAL_ADDRESS         ResourceTop;
> >>    BOOLEAN                      Found;
> >>
> >>    // Get Virtual Memory Map from the Platform Library @@ -121,71
> +117,6 @@ MemoryPeim (
> >>      );
> >>    }
> >>
> >> -  //
> >> -  // Reserved the memory space occupied by the firmware volume
> >> -  //
> >> -
> >> -  SystemMemoryTop = (EFI_PHYSICAL_ADDRESS)PcdGet64
> >> (PcdSystemMemoryBase) + (EFI_PHYSICAL_ADDRESS)PcdGet64
> >> (PcdSystemMemorySize);
> >> -  FdTop = (EFI_PHYSICAL_ADDRESS)PcdGet64 (PcdFdBaseAddress) +
> >> (EFI_PHYSICAL_ADDRESS)PcdGet32 (PcdFdSize);
> >> -
> >> -  // 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
> >> -  if ((PcdGet64 (PcdFdBaseAddress) >= PcdGet64
> (PcdSystemMemoryBase)) && (FdTop <= SystemMemoryTop)) {
> >> -    Found = FALSE;
> >> -
> >> -    // Search for System Memory Hob that contains the firmware
> >> -    NextHob.Raw = GetHobList ();
> >> -    while ((NextHob.Raw = GetNextHob
> (EFI_HOB_TYPE_RESOURCE_DESCRIPTOR, NextHob.Raw)) != NULL) {
> >> -      if ((NextHob.ResourceDescriptor->ResourceType ==
> EFI_RESOURCE_SYSTEM_MEMORY) &&
> >> -          (PcdGet64 (PcdFdBaseAddress) >= NextHob.ResourceDescriptor-
> >PhysicalStart) &&
> >> -          (FdTop <= NextHob.ResourceDescriptor->PhysicalStart +
> NextHob.ResourceDescriptor->ResourceLength))
> >> -      {
> >> -        ResourceAttributes = NextHob.ResourceDescriptor-
> >ResourceAttribute;
> >> -        ResourceLength = NextHob.ResourceDescriptor->ResourceLength;
> >> -        ResourceTop = NextHob.ResourceDescriptor->PhysicalStart +
> ResourceLength;
> >> -
> >> -        if (PcdGet64 (PcdFdBaseAddress) == NextHob.ResourceDescriptor-
> >PhysicalStart) {
> >> -          if (SystemMemoryTop == FdTop) {
> >> -            NextHob.ResourceDescriptor->ResourceAttribute =
> ResourceAttributes & ~EFI_RESOURCE_ATTRIBUTE_PRESENT;
> >> -          } else {
> >> -            // Create the System Memory HOB for the firmware with the non-
> present attribute
> >> -            BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> >> -                                        ResourceAttributes &
> ~EFI_RESOURCE_ATTRIBUTE_PRESENT,
> >> -                                        PcdGet64 (PcdFdBaseAddress),
> >> -                                        PcdGet32 (PcdFdSize));
> >> -
> >> -            // Top of the FD is system memory available for UEFI
> >> -            NextHob.ResourceDescriptor->PhysicalStart +=
> PcdGet32(PcdFdSize);
> >> -            NextHob.ResourceDescriptor->ResourceLength -=
> PcdGet32(PcdFdSize);
> >> -          }
> >> -        } else {
> >> -          // Create the System Memory HOB for the firmware with the non-
> present attribute
> >> -          BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> >> -                                      ResourceAttributes &
> ~EFI_RESOURCE_ATTRIBUTE_PRESENT,
> >> -                                      PcdGet64 (PcdFdBaseAddress),
> >> -                                      PcdGet32 (PcdFdSize));
> >> -
> >> -          // Update the HOB
> >> -          NextHob.ResourceDescriptor->ResourceLength = PcdGet64
> (PcdFdBaseAddress) - NextHob.ResourceDescriptor->PhysicalStart;
> >> -
> >> -          // If there is some memory available on the top of the FD then
> create a HOB
> >> -          if (FdTop < NextHob.ResourceDescriptor->PhysicalStart +
> ResourceLength) {
> >> -            // Create the System Memory HOB for the remaining region (top of
> the FD)
> >> -            BuildResourceDescriptorHob (EFI_RESOURCE_SYSTEM_MEMORY,
> >> -                                        ResourceAttributes,
> >> -                                        FdTop,
> >> -                                        ResourceTop - FdTop);
> >> -          }
> >> -        }
> >> -        Found = TRUE;
> >> -        break;
> >> -      }
> >> -      NextHob.Raw = GET_NEXT_HOB (NextHob);
> >> -    }
> >> -
> >> -    ASSERT(Found);
> >> -  }
> >> -
> >>    // Build Memory Allocation Hob
> >>    InitMmu (MemoryTable);
> >>
> >> --
> >> 1.9.1
> >>
> >> _______________________________________________
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.

  reply	other threads:[~2017-09-25  5:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 14:32 [PATCH] RFC Inform UEFI memory to Linux Meenakshi Aggarwal
2017-09-15 10:13 ` Leif Lindholm
2017-09-15 22:55   ` Ard Biesheuvel
2017-09-18  4:07     ` Udit Kumar
2017-09-18  4:30       ` Ard Biesheuvel
2017-09-19 12:32 ` [PATCH v2] PeiLib : " Meenakshi Aggarwal
2017-09-19  8:07   ` Sakar Arora
2017-09-19 10:10     ` Udit Kumar
2017-09-19 11:20       ` Sakar Arora
2017-09-19 12:46         ` Udit Kumar
2017-09-19 12:48     ` Ard Biesheuvel
2017-09-20  5:32       ` Sakar Arora
2017-09-20  6:32         ` Ard Biesheuvel
2017-09-20  8:20           ` Sakar Arora
2017-09-25  5:47             ` Meenakshi Aggarwal [this message]
2017-11-30 10:07             ` Udit Kumar
2017-11-30 14:33               ` Ard Biesheuvel
2017-09-20 14:59   ` Gao, Liming
2017-09-21  5:59     ` Udit Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB5PR04MB09986AE816072941F9AA98EE8E7A0@DB5PR04MB0998.eurprd04.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox