Shannon, On 11/30/15 13:37, Shannon Zhao wrote: > From: Shannon Zhao <[email protected]> > > Here we add the memory space for the memory nodes except the lowest one > in FDT. So these spaces will show up in the UEFI memory map. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Shannon Zhao <[email protected]> > --- > ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c | 72 > ++++++++++++++++++++++++++++++++++++ > ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf | 4 ++ > 2 files changed, 76 insertions(+) > > diff --git a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > index 74f80d1..11a9b5a 100644 > --- a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > +++ b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > @@ -27,6 +27,7 @@ > #include <Library/HobLib.h> > #include <libfdt.h> > #include <Library/XenIoMmioLib.h> > +#include <Library/DxeServicesTableLib.h> > > #include <Guid/Fdt.h> > #include <Guid/VirtioMmioTransport.h> > @@ -274,6 +275,73 @@ ProcessPciHost ( > return EFI_SUCCESS; > } > > +/** > + Process the device tree node whose "device_type" property is "memory" and > add > + the memory range of this node to System RAM space. > + > + param[in] DeviceTreeBase Pointer to the device tree. > + > + param[in] Node Offset of the device tree node. > + > + @retval TRUE The "device_type" property of this device tree > node > + is "memory" either adding successfully or > + unsuccessfully. > + > + @retval FALSE The "device_type" property of this device tree > node > + is not "memory" > +**/ > +STATIC > +BOOLEAN > +EFIAPI > +AddMemorySpaceToSystemRam ( > + IN CONST VOID *DeviceTreeBase, > + IN INT32 Node > + ) > +{ > + CONST CHAR8 *Type; > + INT32 Len; > + CONST VOID *RegProp; > + EFI_STATUS Status; > + UINT64 CurBase; > + UINT64 CurSize; > + > + // > + // Check for memory node and add the memory spaces expect the lowest one > + // > + Type = fdt_getprop (DeviceTreeBase, Node, "device_type", &Len); > + if (Type && AsciiStrnCmp (Type, "memory", Len) == 0) { > + // > + // Get the 'reg' property of this node. For now, we will assume > + // two 8 byte quantities for base and size, respectively. > + // > + RegProp = fdt_getprop (DeviceTreeBase, Node, "reg", &Len); > + if (RegProp != 0 && Len == (2 * sizeof (UINT64))) { > + > + CurBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]); > + CurSize = fdt64_to_cpu (((UINT64 *)RegProp)[1]); > + > + if (FixedPcdGet64 (PcdSystemMemoryBase) != CurBase) { > + Status = gDS->AddMemorySpace ( > + EfiGcdMemoryTypeSystemMemory, > + CurBase, CurSize, > + EFI_MEMORY_WB | EFI_MEMORY_WC | > + EFI_MEMORY_WT | EFI_MEMORY_UC); > + > + if (EFI_ERROR (Status)) { > + DEBUG ((EFI_D_ERROR, "%a: Failed to add System RAM @ 0x%lx - > 0x%lx\n", > + __FUNCTION__, CurBase, CurBase + CurSize - 1)); > + } else { > + DEBUG ((EFI_D_INFO, "%a: Add System RAM @ 0x%lx - 0x%lx\n", > + __FUNCTION__, CurBase, CurBase + CurSize - 1)); > + } > + } > + } > + > + return TRUE; > + } > + > + return FALSE; > +} > > EFI_STATUS > EFIAPI > @@ -332,6 +400,10 @@ InitializeVirtFdtDxe ( > break; > } > > + if (AddMemorySpaceToSystemRam (DeviceTreeBase, Node)) { > + continue; > + } > + > Type = fdt_getprop (DeviceTreeBase, Node, "compatible", &Len); > if (Type == NULL) { > continue; > diff --git a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > index ee2503a..0e6927b 100644 > --- a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > +++ b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > @@ -43,12 +43,16 @@ > VirtioMmioDeviceLib > HobLib > XenIoMmioLib > + DxeServicesTableLib > > [Guids] > gFdtTableGuid > gVirtioMmioTransportGuid > gFdtHobGuid > > +[FixedPcd] > + gArmTokenSpaceGuid.PcdSystemMemoryBase > + > [Pcd] > gArmVirtTokenSpaceGuid.PcdArmPsciMethod > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress >
Thank you -- this looks better. Unfortunately the SetMemorySpaceAttributes() question still has to be addressed, and we're still discussing with Ard which way to go about that. Once we have an agreement, I'll spell out the further requirements for this. The "do it all in PEI with HOBs" idea is out, now we're trying to decide if (a) we should do it in VirtFdtDxe, and update the APRIORI DXE block in the FDF file so that CpuDxe gets dispatched before VirtFdtDxe, or (b) if we should move this code to a separate DXE driver that depends on the CPU architectural protocol installed by CpuDxe. Whatever the agreement, this patch will need to be further updated. I ask for your patience with this -- it's messier than I would like. I hope your NUMA development can proceed even until we converge with the help of these WIP patches. I'll admit that my secret (well, not so secret :)) agenda with this series is to pull more people into edk2 development from the QEMU community. Albeit somewhat messy, this feature isn't very large or complex, so I find it appropriate to "train" you with it -- if you want to play along, that is. :) Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
