date:20220819

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Rebecca Cran


Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have:


  # Add support for GCC stack protector
  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf


--

Rebecca Cran


On 8/19/22 20:34, Pedro Falcato wrote:
I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC 
toolchains (although arguably we should just enable support for 
it...). Can you try hacking up your tools_def to add 
-fno-stack-protector to GCC_AARCH64_CC_FLAGS? It should fix your build 
issues.


On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran  wrote:

I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on
Ubuntu 20.04.4, from the Ubuntu repo.

I'm building it with:


export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
export WORKSPACE=$PWD
export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-

. ./edk2/edksetup.sh
build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5


Some of the messages are:


"aarch64-linux-gnu-gcc" -o

/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
-Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint

-Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
-z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
-L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto
-llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64
-Wno-lto-type-mismatch

-Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
-g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall
-Werror -Wno-array-bounds -include AutoGen.h -fno-common
-ffunction-sections -fdata-sections
-DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds
-include AutoGen.h -fno-common -mlittle-endian -fno-short-enums
-fverbose-asm -funsigned-char -ffunction-sections -fdata-sections
-Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables
-fno-pic -fno-pie -ffixed-x18 -mcmodel=small -flto
-Wno-unused-but-set-variable -Wno-unused-const-variable -D
DISABLE_NEW_DEPRECATED_INTERFACES
-Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
`InternalAllocatePool.constprop.0':

/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard'
which may bind externally can not be used when making a shared
object; recompile with -fPIC

/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
dangerous relocation: unsupported relocation
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:

/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:

/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
undefined reference to `__stack_chk_fail'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
`OrderedCollectionInsert.constprop.0':

/home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
undefined reference to `__stack_chk_guard'

-- 
Rebecca Cran



On 8/19/22 18:46, Pedro Falcato wrote:

Hi Rebecca,

What EDK2 toolchain are you using? And how is your toolchain
configured (or where did you get it from?)? It seems that it's
trying to use the stack protector automatically...

Thanks,
Pedro


On Sat, 20 Aug 2022, 00:40 Rebecca Cran,  wrote:

./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors
about __stack_chk_guard and __stack_chk_fail.


And I get an error from Andy Hayes' email: "Your message
couldn't be delivered to the recipient because you don't have
permission to send to it."


-- 
Rebecca Cran



On 8/19/22 17:35, Rebecca Cran wrote:


I have an armplatbld.sh script that goes through and tries
to build as many of

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Pedro Falcato

I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC
toolchains (although arguably we should just enable support for it...). Can
you try hacking up your tools_def to add -fno-stack-protector to
GCC_AARCH64_CC_FLAGS? It should fix your build issues.

On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran  wrote:

> I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu
> 20.04.4, from the Ubuntu repo.
>
> I'm building it with:
>
>
> export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
> export WORKSPACE=$PWD
> export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
>
> . ./edk2/edksetup.sh
> build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5
>
>
> Some of the messages are:
>
>
> "aarch64-linux-gnu-gcc" -o
> /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
> -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint
> -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
> -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
> -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64
> -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch
> -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
> -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror
> -Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections
> -fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
> -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include
> AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm
> -funsigned-char -ffunction-sections -fdata-sections -Wno-address
> -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic -fno-pie
> -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable
> -Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES
> -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
> -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
> `InternalAllocatePool.constprop.0':
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
> undefined reference to `__stack_chk_guard'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
> R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may
> bind externally can not be used when making a shared object; recompile with
> -fPIC
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
> dangerous relocation: unsupported relocation
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
> undefined reference to `__stack_chk_guard'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
> undefined reference to `__stack_chk_fail'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
> `OrderedCollectionInsert.constprop.0':
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
> undefined reference to `__stack_chk_guard'
>
> --
> Rebecca Cran
>
>
> On 8/19/22 18:46, Pedro Falcato wrote:
>
> Hi Rebecca,
>
> What EDK2 toolchain are you using? And how is your toolchain configured
> (or where did you get it from?)? It seems that it's trying to use the stack
> protector automatically...
>
> Thanks,
> Pedro
>
>
> On Sat, 20 Aug 2022, 00:40 Rebecca Cran,  wrote:
>
>> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
>> __stack_chk_guard and __stack_chk_fail.
>>
>>
>> And I get an error from Andy Hayes' email: "Your message couldn't be
>> delivered to the recipient because you don't have permission to send to it."
>>
>>
>> --
>> Rebecca Cran
>>
>>
>> On 8/19/22 17:35, Rebecca Cran wrote:
>>
>> I have an armplatbld.sh script that goes through and tries to build as
>> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>>
>> I'm think this used to work for these, but I'm getting some errors now.
>>
>> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and
>> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>
>>
>> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard
>> and __stack_chk_fail)
>>
>>

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Rebecca Cran

I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu 
20.04.4, from the Ubuntu repo.


I'm building it with:


export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
export WORKSPACE=$PWD
export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-

. ./edk2/edksetup.sh
build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5


Some of the messages are:


"aarch64-linux-gnu-gcc" -o 
/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll 
-Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint 
-Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map 
-z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os 
-L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch 
-Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group 
-g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections 
-fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar 
-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds 
-include AutoGen.h -fno-common -mlittle-endian -fno-short-enums 
-fverbose-asm -funsigned-char -ffunction-sections -fdata-sections 
-Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic 
-fno-pie -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable 
-Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES 
-Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function 
`InternalAllocatePool.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: 
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation 
R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may 
bind externally can not be used when making a shared object; recompile 
with -fPIC
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc): 
dangerous relocation: unsupported relocation
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: 
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382: 
undefined reference to `__stack_chk_fail'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function 
`OrderedCollectionInsert.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584: 
undefined reference to `__stack_chk_guard'


--
Rebecca Cran


On 8/19/22 18:46, Pedro Falcato wrote:

Hi Rebecca,

What EDK2 toolchain are you using? And how is your toolchain 
configured (or where did you get it from?)? It seems that it's trying 
to use the stack protector automatically...


Thanks,
Pedro


On Sat, 20 Aug 2022, 00:40 Rebecca Cran,  wrote:

./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
__stack_chk_guard and __stack_chk_fail.


And I get an error from Andy Hayes' email: "Your message couldn't
be delivered to the recipient because you don't have permission to
send to it."


-- 
Rebecca Cran



On 8/19/22 17:35, Rebecca Cran wrote:


I have an armplatbld.sh script that goes through and tries to
build as many of the Arm (AARCH64 and ARM) platforms in
edk2-platforms as possible.

I'm think this used to work for these, but I'm getting some
errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8
and edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.


Drivers/ASIX/Asix.dsc (fails with undefined references to
__stack_chk_guard and __stack_chk_fail)

Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
undefined references to __stack_chk_guard and __stack_chk_fail)
Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with
bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
unsupported symbol type.  For example, absolute and undefined
symbols are not supported.)

Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Pedro Falcato

Hi Rebecca,

What EDK2 toolchain are you using? And how is your toolchain configured (or
where did you get it from?)? It seems that it's trying to use the stack
protector automatically...

Thanks,
Pedro


On Sat, 20 Aug 2022, 00:40 Rebecca Cran,  wrote:

> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
> __stack_chk_guard and __stack_chk_fail.
>
>
> And I get an error from Andy Hayes' email: "Your message couldn't be
> delivered to the recipient because you don't have permission to send to it."
>
>
> --
> Rebecca Cran
>
>
> On 8/19/22 17:35, Rebecca Cran wrote:
>
> I have an armplatbld.sh script that goes through and tries to build as
> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>
> I'm think this used to work for these, but I'm getting some errors now.
>
> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and
> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>
>
> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard
> and __stack_chk_fail)
>
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
> undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad
> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported
> symbol type.  For example, absolute and undefined symbols are not
> supported.)
>
> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references
> to __stack_chk_guard and __stack_chk_fail)
> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
> (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
> unsupported symbol type.  For example, absolute and undefined symbols are
> not supported.)
>
>
> --
> Rebecca Cran
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92588): https://edk2.groups.io/g/devel/message/92588
Mute This Topic: https://groups.io/mt/93135586/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Rebecca Cran

./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about 
__stack_chk_guard and __stack_chk_fail.



And I get an error from Andy Hayes' email: "Your message couldn't be 
delivered to the recipient because you don't have permission to send to it."



--
Rebecca Cran


On 8/19/22 17:35, Rebecca Cran wrote:


I have an armplatbld.sh script that goes through and tries to build as 
many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.


I'm think this used to work for these, but I'm getting some errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.



Drivers/ASIX/Asix.dsc (fails with undefined references to 
__stack_chk_guard and __stack_chk_fail)


Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
undefined references to __stack_chk_guard and __stack_chk_fail)
Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
symbol type.  For example, absolute and undefined symbols are not 
supported.)


Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined 
references to __stack_chk_guard and __stack_chk_fail)
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
unsupported symbol type.  For example, absolute and undefined symbols 
are not supported.)



--
Rebecca Cran





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92587): https://edk2.groups.io/g/devel/message/92587
Mute This Topic: https://groups.io/mt/93135586/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Rebecca Cran

I got an error emailing Masami Hiramatsu , 
who's listed as a reviewer for Socionext platforms and silicon: 
apparently they no longer work at Linaro.



--

Rebecca Cran


On 8/19/22 17:35, Rebecca Cran wrote:


I have an armplatbld.sh script that goes through and tries to build as 
many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.


I'm think this used to work for these, but I'm getting some errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.



Drivers/ASIX/Asix.dsc (fails with undefined references to 
__stack_chk_guard and __stack_chk_fail)


Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
undefined references to __stack_chk_guard and __stack_chk_fail)
Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
symbol type.  For example, absolute and undefined symbols are not 
supported.)


Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined 
references to __stack_chk_guard and __stack_chk_fail)
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
unsupported symbol type.  For example, absolute and undefined symbols 
are not supported.)



--
Rebecca Cran





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92586): https://edk2.groups.io/g/devel/message/92586
Mute This Topic: https://groups.io/mt/93135586/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

2022-08-19 Thread Rebecca Cran

I have an armplatbld.sh script that goes through and tries to build as 
many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.


I'm think this used to work for these, but I'm getting some errors now.

I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.



Drivers/ASIX/Asix.dsc (fails with undefined references to 
__stack_chk_guard and __stack_chk_fail)


Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
undefined references to __stack_chk_guard and __stack_chk_fail)
Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
symbol type.  For example, absolute and undefined symbols are not 
supported.)


Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references 
to __stack_chk_guard and __stack_chk_fail)
Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
unsupported symbol type.  For example, absolute and undefined symbols 
are not supported.)



--
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92585): https://edk2.groups.io/g/devel/message/92585
Mute This Topic: https://groups.io/mt/93135586/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3] DynamicTablesPkg: Add support to build _DSD

2022-08-19 Thread PierreGondois


Thanks for the v3!
Reviewed-by: Pierre Gondois 

On 8/17/22 18:39, Jeff Brasen wrote:

Add APIs needed to build _DSD with different UUIDs.
This is per ACPI specification 6.4 s6.2.5.

Adds support for building data packages with format
Package {"Name", Integer}

Signed-off-by: Jeff Brasen 
---
  .../Include/Library/AmlLib/AmlLib.h   |  60 +
  .../Common/AmlLib/CodeGen/AmlCodeGen.c| 254 ++
  2 files changed, 314 insertions(+)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 6f214c0dfa..18013f3c0c 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1280,6 +1280,66 @@ AmlAddLpiState (
IN  AML_OBJECT_NODE_HANDLE  LpiNode
);
  
+/** AML code generation for a _DSD device data object.

+
+  AmlAddDeviceDataDescriptorPackage (Uuid, DsdNode, PackageNode) is
+  equivalent of the following ASL code:
+ToUUID(Uuid),
+Package () {}
+
+  Cf ACPI 6.4 specification, s6.2.5 "_DSD (Device Specific Data)".
+
+  _DSD (Device Specific Data) Implementation Guide
+  https://github.com/UEFI/DSD-Guide
+  Per s3. "'Well-Known _DSD UUIDs and Data Structure Formats'"
+  If creating a Device Properties data then UUID 
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 should be used.
+
+  @ingroup CodeGenApis
+
+  @param [in]  Uuid   The Uuid of the descriptor to be created
+  @param [in]  DsdNodeNode of the DSD Package.
+  @param [out] PackageNodeIf success, contains the created package node.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+AmlAddDeviceDataDescriptorPackage (
+  IN  CONST EFI_GUID*Uuid,
+  INAML_OBJECT_NODE_HANDLE  DsdNode,
+  OUT   AML_OBJECT_NODE_HANDLE  *PackageNode
+  );
+
+/** AML code generation to add a package with a name and value,
+to a parent package.
+This is useful for build the _DSD package but can be used in other cases.
+
+  AmlAddNameValuePackage ("Name", Value, PackageNode) is
+  equivalent of the following ASL code:
+Package (2) {"Name", Value}
+
+  Cf ACPI 6.4 specification, s6.2.5 "_DSD (Device Specific Data)".
+
+  @ingroup CodeGenApis
+
+  @param [in]  Name   String to place in first entry of package
+  @param [in]  Value  Integer to place in second entry of package
+  @param [in]  PackageNodePackage to add new sub package to.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+AmlAddNameIntegerPackage (
+  IN CHAR8   *Name,
+  IN UINT64  Value,
+  IN AML_OBJECT_NODE_HANDLE  PackageNode
+  );
+
  // DEPRECATED APIS
  #ifndef DISABLE_NEW_DEPRECATED_INTERFACES
  
diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c

index e51d2dd7f0..cf92e7aee7 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -2600,3 +2600,257 @@ error_handler:
  
return Status;

  }
+
+/** AML code generation for a _DSD device data object.
+
+  AmlAddDeviceDataDescriptorPackage (Uuid, DsdNode, PackageNode) is
+  equivalent of the following ASL code:
+ToUUID(Uuid),
+Package () {}
+
+  Cf ACPI 6.4 specification, s6.2.5 "_DSD (Device Specific Data)".
+
+  _DSD (Device Specific Data) Implementation Guide
+  https://github.com/UEFI/DSD-Guide
+  Per s3. "'Well-Known _DSD UUIDs and Data Structure Formats'"
+  If creating a Device Properties data then UUID 
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 should be used.
+
+  @ingroup CodeGenApis
+
+  @param [in]  Uuid   The Uuid of the descriptor to be created
+  @param [in]  DsdNodeNode of the DSD Package.
+  @param [out] PackageNodeIf success, contains the created package node.
+
+  @retval EFI_SUCCESS Success.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_OUT_OF_RESOURCESFailed to allocate memory.
+**/
+EFI_STATUS
+EFIAPI
+AmlAddDeviceDataDescriptorPackage (
+  IN  CONST EFI_GUID*Uuid,
+  INAML_OBJECT_NODE_HANDLE  DsdNode,
+  OUT   AML_OBJECT_NODE_HANDLE  *PackageNode
+  )
+{
+  EFI_STATUS  Status;
+  AML_OBJECT_NODE *UuidNode;
+  AML_DATA_NODE   *UuidDataNode;
+  AML_OBJECT_NODE_HANDLE  DsdEntryList;
+
+  if ((Uuid == NULL) ||
+  (PackageNode == NULL) ||
+  (AmlGetNodeType ((AML_NODE_HANDLE)DsdNode) != EAmlNodeObject) ||
+  (!AmlNodeHasOpCode (DsdNode, AML_NAME_OP, 0)) ||
+  !AmlNameOpCompareName (DsdNode, "_DSD"))
+  {
+ASSERT_EFI_ERROR (EFI_INVALID_PARAMETER);
+return

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in GetControllerName

2022-08-19 Thread Sunny Wang

Looks good.
Reviewed-by: Sunny Wang 

-Original Message-
From: Dimitrije Pavlov 
Sent: 17 August 2022 15:35
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Jiewen Yao 
; Liming Gao ; Sunny Wang 
; Jeff Booher-Kaeding ; Samer 
El-Haj-Mahmoud 
Subject: [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in 
GetControllerName

Per the UEFI specification, a device driver implementation should return
EFI_UNSUPPORTED if the ChildHandle argument in
EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName() is not NULL.

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Liming Gao 
Cc: Sunny Wang 
Cc: Jeff Booher-Kaeding 
Cc: Samer El-Haj-Mahmoud 

Signed-off-by: Dimitrije Pavlov 
---
 OvmfPkg/VirtioNetDxe/ComponentName.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/OvmfPkg/VirtioNetDxe/ComponentName.c 
b/OvmfPkg/VirtioNetDxe/ComponentName.c
index e340ca2f8fe4..718096630f6f 100644
--- a/OvmfPkg/VirtioNetDxe/ComponentName.c
+++ b/OvmfPkg/VirtioNetDxe/ComponentName.c
@@ -129,6 +129,13 @@ VirtioNetGetControllerName (
 return EFI_INVALID_PARAMETER;
   }

+  //
+  // This is a device driver, so ChildHandle must be NULL.
+  //
+  if (ChildHandle != NULL) {
+return EFI_UNSUPPORTED;
+  }
+
   //
   // confirm that the device is managed by this driver, using the VirtIo
   // Protocol
--
2.37.2

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.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92580): https://edk2.groups.io/g/devel/message/92580
Mute This Topic: https://groups.io/mt/93082232/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2] OvmfPkg: Update I/O port related to ACPI devices for CloudHv

2022-08-19 Thread Boeuf, Sebastien

From: Sebastien Boeuf 

Both ACPI shutdown and ACPI PM timer devices has been moved to different
port addresses in the latest version of Cloud Hypervisor. These changes
need to be reflected on the OVMF firmware.

Acked-by: Gerd Hoffmann 
Signed-off-by: Sebastien Boeuf 
---
 OvmfPkg/Include/IndustryStandard/CloudHv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Include/IndustryStandard/CloudHv.h 
b/OvmfPkg/Include/IndustryStandard/CloudHv.h
index d31ecc9eec..527c236f48 100644
--- a/OvmfPkg/Include/IndustryStandard/CloudHv.h
+++ b/OvmfPkg/Include/IndustryStandard/CloudHv.h
@@ -16,12 +16,12 @@
 //
 // ACPI timer address
 //
-#define CLOUDHV_ACPI_TIMER_IO_ADDRESS  0xb008
+#define CLOUDHV_ACPI_TIMER_IO_ADDRESS  0x0608
 
 //
 // ACPI shutdown device address
 //
-#define CLOUDHV_ACPI_SHUTDOWN_IO_ADDRESS  0x03c0
+#define CLOUDHV_ACPI_SHUTDOWN_IO_ADDRESS  0x0600
 
 //
 // 32-bit MMIO memory hole base address
-- 
2.34.1

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92579): https://edk2.groups.io/g/devel/message/92579
Mute This Topic: https://groups.io/mt/93121228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg: Update I/O port related to ACPI devices for CloudHv

2022-08-19 Thread Boeuf, Sebastien

On Mon, 2022-08-15 at 15:49 +0200, Gerd Hoffmann wrote:
> On Thu, Aug 11, 2022 at 02:40:57PM +0200, Boeuf, Sebastien wrote:
> > From: Sebastien Boeuf 
> > 
> > Both ACPI shutdown and ACPI PM timer devices has been moved to
> > different
> > port addresses in the latest version of Cloud Hypervisor. These
> > changes
> > need to be reflected on the OVMF firmware.
> 
> Can this be detected by the guest somehow, so the firmware can work
> with
> both old+new cloudhv?

This information is provided through the FADT/FACP as well, which is
where the OS retrieves it.

> 
> Requiring lockstep updates tends to be painful, so we try avoid that
> with qemu ...

Yes I understand. We've been kind of forced to update these addresses
to match the ones used by QEMU since they had already been authorized
in the context of TDX. It's just easier for everybody.

> 
> (just a suggestion, not an objection)
> 
> Acked-by: Gerd Hoffmann 
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 5 208 026.16 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92578): https://edk2.groups.io/g/devel/message/92578
Mute This Topic: https://groups.io/mt/92957046/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 2/2] Dynamic Tbl Mgr: MPAM: MPAM Generator and supporting files

2022-08-19 Thread Rohit Mathew

Hi Swatisri,

Thanks for the patch. Please find my comments inline marked [Rohit] - 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Name
> via groups.io
> Sent: 16 August 2022 21:18
> To: devel@edk2.groups.io; Sami Mujawar ;
> Alexei Fedorov ; michael.d.kin...@intel.com;
> gaolim...@byosoft.com.cn; zhiguang@intel.com
> Cc: Swatisri Kantamsetti 
> Subject: [edk2-devel] [PATCH 2/2] Dynamic Tbl Mgr: MPAM: MPAM
> Generator and supporting files
> 
> From: Swatisri Kantamsetti 
> 
> ACPI header, MSC and Resource Nodes are populated in the MPAM Table
> 
> Signed-off-by: Swatisri Kantamsetti 
> ---
>  DynamicTablesPkg/DynamicTables.dsc.inc|   2 +
>  DynamicTablesPkg/Include/AcpiTableGenerator.h |   1 +
>  .../Include/ArmNameSpaceObjects.h |  68 ++
>  .../Arm/AcpiMpamLibArm/AcpiMpamLibArm.inf |  30 +
>  .../Acpi/Arm/AcpiMpamLibArm/MpamGenerator.c   | 649
> ++
>  .../Acpi/Arm/AcpiMpamLibArm/MpamGenerator.h   |  47 ++
>  6 files changed, 797 insertions(+)
>  create mode 100644
> DynamicTablesPkg/Library/Acpi/Arm/AcpiMpamLibArm/AcpiMpamLibArm.in
> f
>  create mode 100644
> DynamicTablesPkg/Library/Acpi/Arm/AcpiMpamLibArm/MpamGenerator.c
>  create mode 100644
> DynamicTablesPkg/Library/Acpi/Arm/AcpiMpamLibArm/MpamGenerator.h
> 
> diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc
> b/DynamicTablesPkg/DynamicTables.dsc.inc
> index 3d4fa0c4c4..745d5f0633 100644
> --- a/DynamicTablesPkg/DynamicTables.dsc.inc
> +++ b/DynamicTablesPkg/DynamicTables.dsc.inc
> @@ -29,6 +29,7 @@
>DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/AcpiIortLibArm.inf
>DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibArm.inf
>DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.inf
> +
> DynamicTablesPkg/Library/Acpi/Arm/AcpiMpamLibArm/AcpiMpamLibArm.in
> f
>DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf
>DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.inf
>DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf
> @@ -54,6 +55,7 @@
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibAr
> m.inf
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibAr
> m.inf
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.
> inf
> +
> +
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMpamLibArm/AcpiMpamLib
> Arm.i
> + nf
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.
> inf
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.
> inf
> 
> NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSratLibArm/AcpiSratLibArm.i
> nf
> diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h
> b/DynamicTablesPkg/Include/AcpiTableGenerator.h
> index f962dbff57..56d7375b4a 100644
> --- a/DynamicTablesPkg/Include/AcpiTableGenerator.h
> +++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h
> @@ -94,6 +94,7 @@ typedef enum StdAcpiTableId {
>EStdAcpiTableIdIort,  ///< IORT Generator
>EStdAcpiTableIdPptt,  ///< PPTT Generator
>EStdAcpiTableIdSrat,  ///< SRAT Generator
> +  EStdAcpiTableIdMpam,  ///< MPAM Generator
>EStdAcpiTableIdSsdtSerialPort,///< SSDT Serial-Port 
> Generator
>EStdAcpiTableIdSsdtCmn600,///< SSDT Cmn-600 Generator
>EStdAcpiTableIdSsdtCpuTopology,   ///< SSDT Cpu Topology
> diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> index 102e0f96be..39a14ed0b3 100644
> --- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> +++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> @@ -63,6 +63,8 @@ typedef enum ArmObjectID {
>EArmObjPciInterruptMapInfo,  ///< 39 - Pci Interrupt Map Info
>EArmObjRmr,  ///< 40 - Reserved Memory Range Node
>EArmObjMemoryRangeDescriptor,///< 41 - Memory Range Descriptor
> +  EArmObjMscNodeInfo,  ///< 40 - Msc Memory System Controller
> Node Info
> +  EArmObjResNodeInfo,  ///< 41 - Res Resource Node Info
>EArmObjMax
>  } EARM_OBJECT_ID;
> 
> @@ -1070,6 +1072,72 @@ typedef struct CmArmRmrDescriptor {
>UINT64Length;
>  } CM_ARM_MEMORY_RANGE_DESCRIPTOR;
> 
> +/** A structure that describes Memory System Controller Node.
> +
> +MPAM Memory System Component Nodes are described by
> +this object.
> +
> +  ID: EArmObjMscNodeInfo
> +*/
> +typedef struct CmArmMscNodeInfo {
> +  /// An unique token used to identify this object
> +  CM_OBJECT_TOKEN  Token;
> +
> +  /// MPAM Base Address
> +  UINT64   BaseAddress;
> +  /// MMIO Size
> +  UINT32   MmioSize;
> +  /// Overflow Interrupt
> +  UINT32   OverflowInterrupt;
> +  /// Overflow Interrupt Flags
> +  UINT32   OverflowInterruptFlags;

[Rohit] I have added a comment on Flag's

Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

2022-08-19 Thread Rohit Mathew

Hi Swatisri,

Thanks for the patch. Please find my comments inline marked [Rohit] -

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Name
> via groups.io
> Sent: 16 August 2022 21:18
> To: devel@edk2.groups.io; Sami Mujawar ;
> Alexei Fedorov ; michael.d.kin...@intel.com;
> gaolim...@byosoft.com.cn; zhiguang@intel.com
> Cc: Swatisri Kantamsetti 
> Subject: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table
> 
> From: Swatisri Kantamsetti 
> 
> Added MPAM table header, MSC and Resource Node info structures
> 
> Signed-off-by: Swatisri Kantamsetti 
> ---
>  MdePkg/Include/IndustryStandard/Acpi64.h |  5 ++
>  MdePkg/Include/IndustryStandard/Mpam.h   | 69
> 
>  2 files changed, 74 insertions(+)
>  create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi64.h
> b/MdePkg/Include/IndustryStandard/Acpi64.h
> index fe5ebfac2b..e54f631186 100644
> --- a/MdePkg/Include/IndustryStandard/Acpi64.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi64.h
> @@ -2952,6 +2952,11 @@ typedef struct {
>  ///
>  #define
> EFI_ACPI_6_4_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SI
> GNATURE  SIGNATURE_32('P', 'P', 'T', 'T')
> 
> +///
> +/// "MPAM" Memory System Resource Partitioning And Monitoring Table
> ///
> +#define
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_STRUC
> +TURE_SIGNATURE  SIGNATURE_32('M', 'P', 'A', 'M')
> +
>  ///
>  /// "PSDT" Persistent System Description Table  /// diff --git
> a/MdePkg/Include/IndustryStandard/Mpam.h
> b/MdePkg/Include/IndustryStandard/Mpam.h
> new file mode 100644
> index 00..e0f75f0114
> --- /dev/null
> +++ b/MdePkg/Include/IndustryStandard/Mpam.h
> @@ -0,0 +1,69 @@
> +/** @file
> +  ACPI Memory System Resource Partitioning And Monitoring (MPAM)
> +  as specified in ARM spec DEN0065
> +
> +  Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
> +  Copyright (c) 2022, ARM Limited. All rights reserved.
> +  SPDX-License-Identifier: BSD-2-Clause-Patent **/
> +
> +#ifndef _MPAM_H_
> +#define _MPAM_H_
> +
> +#pragma pack(1)
> +
> +///
> +/// Memory System Resource Partitioning and Monitoring Table (MPAM)
> ///
> +typedef struct {
> +  EFI_ACPI_DESCRIPTION_HEADERHeader;
> +  UINT32 NumNodes;
> +  UINT32 NodeOffset;
> +  UINT32 Reserved;
> +}
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_HEADE
> +R;

[Rohit] Shouldn't the header be followed by MSC node body type as defined in 
MPAM ACPI 1.0, section 2, table 3 - The MPAM table and section 2.1, table 4 - 
MSC Node body?

> +
> +///
> +/// MPAM Revision (as defined in ACPI 6.4 spec.) /// #define
> +EFI_ACPI_6_4_MEMORY_SYSTEM_RESOURCE_PARTITIONING_MONITORI
> NG_TABLE_REVIS
> +ION  0x01
> +
> +///
> +/// Memory System Controller Node Structure ///
> +
> +typedef struct {
> +  UINT16Length;
> +  UINT16Reserved;
> +  UINT32Identifier;
> +  UINT64BaseAddress;
> +  UINT32MmioSize;
> +  UINT32OverflowInterrupt;
> +  UINT32OverflowInterruptFlags;

[Rohit] Would it be better to have a type (possibly bitfield struct) instead of 
a plain UINT32 for Flags? (MPAM ACPI 1.0, section 2.1.1, table 5 - Interrupt 
flags)

> +  UINT32Reserved1;
> +  UINT32OverflowInterruptAff;
> +  UINT32ErrorInterrupt;
> +  UINT32ErrorInterruptFlags;

[Rohit ] Same comment as before above.

> +  UINT32Reserved2;
> +  UINT32ErrorInterruptAff;
> +  UINT32MaxNRdyUsec;
> +  UINT64LinkedDeviceHwId;
> +  UINT32LinkedDeviceInstanceHwId;
> +  UINT32NumResourceNodes;
> +} EFI_ACPI_6_4_MPAM_MSC_NODE;
> +
> +///
> +/// Resource Node Structure
> +///
> +
> +typedef struct {
> +  UINT32Identifier;
> +  UINT8 RisIndex;
> +  UINT16Reserved1;
> +  UINT8 LocatorType;
> +  UINT64Locator;

[Rohit ] Shouldn't " Locator " field be 12 bytes in size, possibly a separate 
type? (MPAM ACPI 1.0, section 2.2, table 7 - Resource node and section 2.3.2 
table 10 - locator descriptor)

> +  UINT32NumFuncDep;
> +} EFI_ACPI_6_4_MPAM_RESOURCE_NODE;

[Rohit] Since "NumFuncDep" field is part of EFI_ACPI_6_4_MPAM_RESOURCE_NODE 
type and this could be non-zero, should we also need the type for functional 
dependency descriptors? (MPAM ACPI 1.0, section 2.2.1, table 8 - Functional 
dependency descriptor)

[Rohit] Also, could some of the commonly used macros be added to this header, 
please? (location types, MPAM interrupt mode, interrupt types, affinity type, 
etc)

> +
> +#pragma pack()
> +
> +#endif
> --
> 2.17.1
> 
> 
> 
> 
> 

Regards,
Rohit



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92575): https://edk2.groups.io/g/devel/message/92575
Mute This Topic: https://groups.io/mt/93069490/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Silicon/SynQuacer/PlatformDxe: set ACPI as default hardware description

2022-08-19 Thread Ard Biesheuvel

On Fri, 19 Aug 2022 at 09:00, Masahisa Kojima
 wrote:
>
> Since ACPI is well supported on SynQuacer platform, set ACPI as
> default hardware description.
>
> Only changing the "DEFAULT" flags from ACPIPREF_DT to ACPIPREF_ACPI
> does not work as expected, this commit also replaces the value
> of ACPIPREF_DT and ACPIPREF_ACPI.
>
> Signed-off-by: Masahisa Kojima 

Reviewed-by: Ard Biesheuvel 

Pushed as 1096b98314e6..46686eeb7e78

Thanks!

> ---
>  Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h| 4 ++--
>  Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h 
> b/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
> index 6ac63e64ecbd..271a340e74b4 100644
> --- a/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
> +++ b/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
> @@ -16,8 +16,8 @@
>  #define PCIE_MAX_SPEED_UNLIMITED  0x0
>  #define PCIE_MAX_SPEED_GEN1   0x1
>
> -#define ACPIPREF_DT   0x0
> -#define ACPIPREF_ACPI 0x1
> +#define ACPIPREF_ACPI 0x0
> +#define ACPIPREF_DT   0x1
>
>  typedef struct {
>UINT8 EnableEmmc;
> diff --git 
> a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
> b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
> index 6707687b279a..6e6c89c3eccd 100644
> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
> @@ -61,8 +61,8 @@ formset
>  prompt  = STRING_TOKEN(STR_DT_ACPI_SELECT_PROMPT),
>  help= STRING_TOKEN(STR_DT_ACPI_SELECT_HELP),
>  flags   = NUMERIC_SIZE_1 | INTERACTIVE | RESET_REQUIRED,
> -option text = STRING_TOKEN(STR_DT_ACPI_SELECT_DT), value = 
> ACPIPREF_DT, flags = DEFAULT;
> -option text = STRING_TOKEN(STR_DT_ACPI_SELECT_ACPI), value = 
> ACPIPREF_ACPI, flags = 0;
> +option text = STRING_TOKEN(STR_DT_ACPI_SELECT_ACPI), value = 
> ACPIPREF_ACPI, flags = DEFAULT;
> +option text = STRING_TOKEN(STR_DT_ACPI_SELECT_DT), value = 
> ACPIPREF_DT, flags = 0;
>  endoneof;
>
>  subtitle text = STRING_TOKEN(STR_NULL_STRING);
> --
> 2.17.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92574): https://edk2.groups.io/g/devel/message/92574
Mute This Topic: https://groups.io/mt/93120018/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] CloudHv/arm: switch PeiMemLib to its own

2022-08-19 Thread Jianyong Wu

As Cloud Hypervisor has its own PeiMemLib, change it in dsc file
accordingly.

Signed-off-by: Jianyong Wu 
Reviewed-by: Sami Mujawar 
---
 ArmVirtPkg/ArmVirtCloudHv.dsc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc b/ArmVirtPkg/ArmVirtCloudHv.dsc
index 7559386a1d..7ca7a391d9 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -60,7 +60,7 @@
 !include MdePkg/MdeLibs.dsc.inc
 
 [LibraryClasses.common.PEIM]
-  
ArmVirtMemInfoLib|ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
+  
ArmVirtMemInfoLib|ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoPeiLib.inf
 
 [LibraryClasses.common.DXE_DRIVER]
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92573): https://edk2.groups.io/g/devel/message/92573
Mute This Topic: https://groups.io/mt/93120532/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/2] CloudHv/arm: add PeiMemInfoLib

2022-08-19 Thread Jianyong Wu

Memory layout in CLoud Hypervisor for arm is changed and is different
with Qemu, thus we should build its own PeiMemInfoLib.
The main change in the memory layout is that normal ram may not contiguous
under 4G. The top 64M under 4G is reserved for 32bit device.

What this patch does:
1. get all of the memory node from DT;
2. Add all of the memory nodes to Hob;
3. Init page table for each memory node;

Signed-off-by: Jianyong Wu 
---
 .../CloudHvVirtMemInfoLib.c   | 230 ++
 .../CloudHvVirtMemInfoLib.h   |  42 
 .../CloudHvVirtMemInfoPeiLib.inf  |  46 
 3 files changed, 318 insertions(+)
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.c
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.h
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoPeiLib.inf

diff --git a/ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.c 
b/ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.c
new file mode 100644
index 00..d9c434754e
--- /dev/null
+++ b/ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.c
@@ -0,0 +1,230 @@
+/** @file
+
+  Copyright (c) 2022, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "CloudHvVirtMemInfoLib.h"
+
+CLOUDHV_MEM_NODE_INFO CloudHvMemNode[CLOUDHV_MAX_MEM_NODE_NUM];
+
+RETURN_STATUS
+EFIAPI
+CloudHvVirtMemInfoPeiLibConstructor (
+  VOID
+  )
+{
+  VOID   *DeviceTreeBase;
+  EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;
+  INT32  Node, Prev;
+  UINT64 FirMemNodeBase, FirMemNodeSize;
+  UINT64 CurBase, MemBase;
+  UINT64 CurSize;
+  CONST CHAR8*Type;
+  INT32  Len;
+  CONST UINT64   *RegProp;
+  RETURN_STATUS  PcdStatus;
+  UINT8  Index;
+
+  ZeroMem (CloudHvMemNode, sizeof(CloudHvMemNode));
+
+  FirMemNodeBase = 0;
+  FirMemNodeSize = 0;
+  Index = 0;
+  MemBase = FixedPcdGet64 (PcdSystemMemoryBase);
+  ResourceAttributes = (
+EFI_RESOURCE_ATTRIBUTE_PRESENT |
+EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_TESTED
+);
+  DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeInitialBaseAddress);
+  if (DeviceTreeBase == NULL) {
+return EFI_NOT_FOUND;
+  }
+
+  //
+  // Make sure we have a valid device tree blob
+  //
+  if (fdt_check_header (DeviceTreeBase) != 0) {
+return EFI_NOT_FOUND;
+  }
+
+  //
+  // Look for the lowest memory node
+  //
+  for (Prev = 0; ; Prev = Node) {
+Node = fdt_next_node (DeviceTreeBase, Prev, NULL);
+if (Node < 0) {
+  break;
+}
+
+//
+// Check for memory node
+//
+Type = fdt_getprop (DeviceTreeBase, Node, "device_type", );
+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", );
+  if ((RegProp != 0) && (Len == (2 * sizeof (UINT64 {
+CurBase = fdt64_to_cpu (ReadUnaligned64 (RegProp));
+CurSize = fdt64_to_cpu (ReadUnaligned64 (RegProp + 1));
+
+DEBUG ((
+  DEBUG_INFO,
+  "%a: System RAM @ 0x%lx - 0x%lx\n",
+  __FUNCTION__,
+  CurBase,
+  CurBase + CurSize - 1
+  ));
+
+// We should build Hob seperately for the memory node except the first 
one
+if (CurBase != MemBase) {
+  BuildResourceDescriptorHob (
+EFI_RESOURCE_SYSTEM_MEMORY,
+ResourceAttributes,
+CurBase,
+CurSize
+);
+} else {
+  FirMemNodeBase = CurBase;
+  FirMemNodeSize = CurSize;
+}
+
+CloudHvMemNode[Index].Base = CurBase;
+CloudHvMemNode[Index].Size = CurSize;
+Index++;
+
+if (Index >= CLOUDHV_MAX_MEM_NODE_NUM) {
+  DEBUG ((
+DEBUG_WARN,
+"%a: memory node larger than %d will not be included into Memory 
System\n",
+__FUNCTION__,
+CLOUDHV_MAX_MEM_NODE_NUM
+));
+  break;
+}
+  } else {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Failed to parse FDT memory node\n",
+  __FUNCTION__
+  ));
+  }
+}
+  }
+
+  //
+  // Make sure the start of DRAM matches our expectation
+  //
+  if (FixedPcdGet64 (PcdSystemMemoryBase) != FirMemNodeBase) {
+return EFI_NOT_FOUND;
+  }
+  PcdStatus = PcdSet64S (PcdSystemMemorySize, FirMemNodeSize);
+  ASSERT_RETURN_ERROR (PcdStatus);
+  ASSERT (
+(((UINT64)PcdGet64

[edk2-devel] [PATCH v2 0/2] CloudHv/arm: Add specific mem info lib

2022-08-19 Thread Jianyong Wu

Currently, the meminfo lib for CloudHv/arm is reusing QEMU's. As the memory
layout for cloud hypervisor is changed, it needs a new meminfo lib.

Signed-off-by: Jianyong Wu 

Jianyong Wu (2):
  CloudHv/arm: add PeiMemInfoLib
  CloudHv/arm: switch PeiMemLib to its own

 ArmVirtPkg/ArmVirtCloudHv.dsc |   2 +-
 .../CloudHvVirtMemInfoLib.c   | 230 ++
 .../CloudHvVirtMemInfoLib.h   |  42 
 .../CloudHvVirtMemInfoPeiLib.inf  |  46 
 4 files changed, 319 insertions(+), 1 deletion(-)
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.c
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoLib.h
 create mode 100644 
ArmVirtPkg/Library/CloudHvVirtMemInfoLib/CloudHvVirtMemInfoPeiLib.inf

-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92571): https://edk2.groups.io/g/devel/message/92571
Mute This Topic: https://groups.io/mt/93120530/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V4 3/3] RedfishPkg: Redfish functions for REST requests are not fully spec complied

2022-08-19 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

Reviewed-by: Abner Chang 

Thanks!

> -Original Message-
> From: Igor Kulchytskyy 
> Sent: Friday, August 19, 2022 3:41 AM
> To: devel@edk2.groups.io
> Cc: Chang, Abner ; nickle.w...@hpe.com; Igor
> Kulchytskyy ; Chang, Abner 
> Subject: [PATCH V4 3/3] RedfishPkg: Redfish functions for REST requests are
> not fully spec complied
> 
> [CAUTION: External Email]
> 
> There is no function to send POST request with the ContentType different
> from "application\json".
> There is no function to send DELETE request with the body.
> 
> Cc: Abner Chang 
> Cc: Nickle Wang 
> Signed-off-by: Igor Kulchytskyy 
> ---
>  RedfishPkg/Include/Library/RedfishLib.h  
> |  80 +
>  RedfishPkg/PrivateLibrary/RedfishLib/RedfishLib.c
> | 189
> 
> 
> RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/include/redfishService.
> h |   8 +
>  RedfishPkg/PrivateLibrary/RedfishLib/edk2libredfish/src/service.c
> |  41
> -
>  4 files changed, 316 insertions(+), 2 deletions(-)
> 
> diff --git a/RedfishPkg/Include/Library/RedfishLib.h
> b/RedfishPkg/Include/Library/RedfishLib.h
> index b2488ab..ce39ce3 100644
> --- a/RedfishPkg/Include/Library/RedfishLib.h
> +++ b/RedfishPkg/Include/Library/RedfishLib.h
> @@ -380,6 +380,49 @@ RedfishPatchToPayload (
>OUTREDFISH_RESPONSE  *RedResponse
>);
> 
> +
> +/**
> +  Use HTTP POST to create new Redfish resource in the Resource Collection.
> +
> +  The POST request should be submitted to the Resource Collection in
> + which the new resource  is to belong. The Resource Collection is
> + addressed by URI. The Redfish may  ignore any service controlled
> + properties. The corresponding redfish response will returned,  including
> HTTP StatusCode, Headers and Payload which record any HTTP response
> messages.
> +
> +  Callers are responsible for freeing the HTTP StatusCode, Headers and
> + Payload returned in  redfish response data.
> +
> +  @param[in]RedfishServiceThe Service to access the Redfish
> resources.
> +  @param[in]Uri   Relative path to address the resource.
> +  @param[in]Content   JSON represented properties to be 
> update.
> +  @param[in]ContentSize   Size of the Content to be send to 
> Redfish
> service
> +  @param[in]ContentType   Type of the Content to be send to 
> Redfish
> service
> +  @param[out]   RedResponse   Pointer to the Redfish response data.
> +
> +  @retval EFI_SUCCESS The opeartion is successful, indicates the 
> HTTP
> StatusCode is not
> +  NULL and the value is 2XX. The Redfish 
> resource will be
> returned
> +  in Payload within RedResponse if server 
> send it back in the
> HTTP
> +  response message body.
> +  @retval EFI_INVALID_PARAMETER   RedfishService, Uri, Content, or
> RedResponse is NULL.
> +  @retval EFI_DEVICE_ERRORAn unexpected system or network error
> occurred. Callers can get
> +  more error info from returned HTTP 
> StatusCode, Headers
> and Payload
> +  within RedResponse:
> +  1. If the returned StatusCode is NULL, 
> indicates any error
> happen.
> +  2. If the returned StatusCode is not NULL 
> and the value is
> not 2XX,
> + indicates any error happen.
> +**/
> +EFI_STATUS
> +EFIAPI
> +RedfishPostToUri (
> +  IN REDFISH_SERVICE   RedfishService,
> +  IN CONST CHAR8   *Uri,
> +  IN CONST CHAR8   *Content,
> +  IN UINTN ContentSize,
> +  IN CONST CHAR8   *ContentType,
> +  OUTREDFISH_RESPONSE  *RedResponse
> +  );
> +
> +
>  /**
>Use HTTP POST to create a new resource in target payload.
> 
> @@ -451,6 +494,43 @@ RedfishDeleteByUri (
>);
> 
>  /**
> +  Use HTTP DELETE to remove a resource.
> +
> +  This function uses the RedfishService to remove a Redfish resource
> + which is addressed  by input Uri (only the relative path is required).
> + The corresponding redfish response will  returned, including HTTP
> + StatusCode, Headers and Payload which record any HTTP response
> messages.
> +
> +  Callers are responsible for freeing the HTTP StatusCode, Headers and
> + Payload returned in  redfish response data.
> +
> +  @param[in]RedfishServiceThe Service to access the Redfish
> resources.
> +  @param[in]Uri   Relative path to address the resource.
> +  @param[in]Content   JSON represented properties to be 
> deleted.
> +  @param[out]   RedResponse   Pointer to the Redfish response data.
> +
> +  @retval EFI_SUCCESS The opeartion is successful, indicates the 
> HTTP
> StatusCode is not
> +

Re: [edk2-devel] [PATCH 1/2] CloudHv/arm: add PeiMemInfoLib

2022-08-19 Thread Jianyong Wu

Thanks Sami. I will fix them all and send the v2 later.

From: Sami Mujawar 
Sent: Thursday, August 18, 2022 7:41 PM
To: Jianyong Wu ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; Justin He ; 
nd 
Subject: Re: [edk2-devel] [PATCH 1/2] CloudHv/arm: add PeiMemInfoLib

Hi Jianyong,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar

From: Jianyong Wu mailto:jianyong...@arm.com>>
Date: Thursday, 18 August 2022 at 06:22
To: "devel@edk2.groups.io" 
mailto:devel@edk2.groups.io>>, Jianyong Wu 
mailto:jianyong...@arm.com>>, Sami Mujawar 
mailto:sami.muja...@arm.com>>
Cc: Ard Biesheuvel 
mailto:ardb+tianoc...@kernel.org>>, Justin He 
mailto:justin...@arm.com>>, nd 
mailto:n...@arm.com>>
Subject: RE: [edk2-devel] [PATCH 1/2] CloudHv/arm: add PeiMemInfoLib

Hi Sami,

Thanks for review. All the comments are Ok for me. Just one inline reply:


+

+struct CloudHvMemNodeInfo CloudHvMemNode[CLOUDHV_MAX_MEM_NODE_NUM];

+

+RETURN_STATUS

+EFIAPI

+CloudHvVirtMemInfoPeiLibConstructor (

+  VOID

+  )

+{

+  VOID   *DeviceTreeBase;

+  EFI_RESOURCE_ATTRIBUTE_TYPE  ResourceAttributes;

+  INT32  Node, Prev;

+  UINT64 CurBase, MemBase;

+  UINT64 CurSize;

+  CONST CHAR8*Type;

+  INT32  Len;

+  CONST UINT64   *RegProp;

+  RETURN_STATUS  PcdStatus;

+  UINT8  Index;

+

+  ZeroMem (CloudHvMemNode, sizeof(CloudHvMemNode[0]) * 
CLOUDHV_MAX_MEM_NODE_NUM);
[SAMI] Will sizeof (CloudHvMemNode) should be sufficient above? Also, can you 
run uncrustify on your patches, please?

[Jong] The local uncrustify test environment is not ready. But I think “sizeof” 
here is OK, as this struct contains only two u64 variables, thus no padding 
here. If sizeof is not preference here, is there any suggestion from you?
[SAMI] I think you could just use

+  ZeroMem (CloudHvMemNode, sizeof(CloudHvMemNode));

Also, let me know if you need any help to get uncrustify working locally. I 
will dig out the relevant information for you.

[/SAMI]


Thanks
Jianyong




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92569): https://edk2.groups.io/g/devel/message/92569
Mute This Topic: https://groups.io/mt/92686349/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 1/1] Silicon/SynQuacer/PlatformDxe: set ACPI as default hardware description

2022-08-19 Thread Masahisa Kojima

Since ACPI is well supported on SynQuacer platform, set ACPI as
default hardware description.

Only changing the "DEFAULT" flags from ACPIPREF_DT to ACPIPREF_ACPI
does not work as expected, this commit also replaces the value
of ACPIPREF_DT and ACPIPREF_ACPI.

Signed-off-by: Masahisa Kojima 
---
 Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h| 4 ++--
 Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h 
b/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
index 6ac63e64ecbd..271a340e74b4 100644
--- a/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
+++ b/Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h
@@ -16,8 +16,8 @@
 #define PCIE_MAX_SPEED_UNLIMITED  0x0
 #define PCIE_MAX_SPEED_GEN1   0x1
 
-#define ACPIPREF_DT   0x0
-#define ACPIPREF_ACPI 0x1
+#define ACPIPREF_ACPI 0x0
+#define ACPIPREF_DT   0x1
 
 typedef struct {
   UINT8 EnableEmmc;
diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr 
b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
index 6707687b279a..6e6c89c3eccd 100644
--- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
+++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr
@@ -61,8 +61,8 @@ formset
 prompt  = STRING_TOKEN(STR_DT_ACPI_SELECT_PROMPT),
 help= STRING_TOKEN(STR_DT_ACPI_SELECT_HELP),
 flags   = NUMERIC_SIZE_1 | INTERACTIVE | RESET_REQUIRED,
-option text = STRING_TOKEN(STR_DT_ACPI_SELECT_DT), value = 
ACPIPREF_DT, flags = DEFAULT;
-option text = STRING_TOKEN(STR_DT_ACPI_SELECT_ACPI), value = 
ACPIPREF_ACPI, flags = 0;
+option text = STRING_TOKEN(STR_DT_ACPI_SELECT_ACPI), value = 
ACPIPREF_ACPI, flags = DEFAULT;
+option text = STRING_TOKEN(STR_DT_ACPI_SELECT_DT), value = 
ACPIPREF_DT, flags = 0;
 endoneof;
 
 subtitle text = STRING_TOKEN(STR_NULL_STRING);
-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#92568): https://edk2.groups.io/g/devel/message/92568
Mute This Topic: https://groups.io/mt/93120018/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [Patch V2] UefiCpuPkg: Use Top of each AP's stack to save CpuMpData

2022-08-19 Thread Yuanhao Xie

From: Yuanhao Xie 

To remove the dependency of CPU register, 4/8 byte at the top of the
stack is occupied for CpuMpData. BIST information is also taken care
here. This modification is only for PEI phase, since in DXE phase
CpuMpData is accessed via global variable.

Change-Id: I7564279544622617c322310b4c7028ac0e11a9c4
Signed-off-by: Yuanhao 
Cc: Eric Dong 
Cc: Ray Ni 
Cc: Rahul Kumar 
---
 .../Library/MpInitLib/Ia32/MpFuncs.nasm   |  8 
 UefiCpuPkg/Library/MpInitLib/MpLib.c  | 37 ++-
 UefiCpuPkg/Library/MpInitLib/MpLib.h  |  8 
 UefiCpuPkg/Library/MpInitLib/PeiMpLib.c   | 10 +++--
 UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm |  9 +
 5 files changed, 59 insertions(+), 13 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm 
b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
index 28301bb8f0..2625d28401 100644
--- a/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
+++ b/UefiCpuPkg/Library/MpInitLib/Ia32/MpFuncs.nasm
@@ -179,6 +179,14 @@ ProgramStack:
 mov esp, dword [edi + CPU_INFO_IN_HOB.ApTopOfStack]
 
 CProcedureInvoke:
+;
+; Reserve 4 bytes for CpuMpData.
+; When the AP wakes up again via INIT-SIPI-SIPI, push 0 will cause the 
existing CpuMpData to be overwritten with 0.
+; CpuMpData is filled in via InitializeApData() during the first time 
INIT-SIPI-SIPI,
+; while overwirrten may occurs when under ApInHltLoop but InitFlag is not 
set to ApInitConfig.
+; Therefore reservation is implemented by sub esp instead of push 0.
+;
+subesp, 4
 push   ebp   ; push BIST data at top of AP stack
 xorebp, ebp  ; clear ebp for call stack trace
 push   ebp
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 8d1f24370a..a4ce1c6d2e 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -571,6 +571,7 @@ InitializeApData (
 {
   CPU_INFO_IN_HOB*CpuInfoInHob;
   MSR_IA32_PLATFORM_ID_REGISTER  PlatformIdMsr;
+  AP_STACK_DATA  *ApStackData;
 
   CpuInfoInHob= (CPU_INFO_IN_HOB 
*)(UINTN)CpuMpData->CpuInfoInHob;
   CpuInfoInHob[ProcessorNumber].InitialApicId = GetInitialApicId ();
@@ -578,6 +579,12 @@ InitializeApData (
   CpuInfoInHob[ProcessorNumber].Health= BistData;
   CpuInfoInHob[ProcessorNumber].ApTopOfStack  = ApTopOfStack;
 
+  //
+  // AP_STACK_DATA is stored at the top of AP Stack
+  //
+  ApStackData = (AP_STACK_DATA *)((UINTN)ApTopOfStack - sizeof 
(AP_STACK_DATA));
+  ApStackData->MpData = CpuMpData;
+
   CpuMpData->CpuData[ProcessorNumber].Waiting= FALSE;
   CpuMpData->CpuData[ProcessorNumber].CpuHealthy = (BistData == 0) ? TRUE : 
FALSE;
 
@@ -623,6 +630,7 @@ ApWakeupFunction (
   CPU_INFO_IN_HOB   *CpuInfoInHob;
   UINT64ApTopOfStack;
   UINTN CurrentApicMode;
+  AP_STACK_DATA *ApStackData;
 
   //
   // AP finished assembly code and begin to execute C code
@@ -648,7 +656,9 @@ ApWakeupFunction (
   // This is first time AP wakeup, get BIST information from AP stack
   //
   ApTopOfStack = CpuMpData->Buffer + (ProcessorNumber + 1) * 
CpuMpData->CpuApStackSize;
-  BistData = *(UINT32 *)((UINTN)ApTopOfStack - sizeof (UINTN));
+  ApStackData  = (AP_STACK_DATA *)((UINTN)ApTopOfStack - sizeof 
(AP_STACK_DATA));
+  BistData = (UINT32)ApStackData->Bist;
+
   //
   // CpuMpData->CpuData[0].VolatileRegisters is initialized based on BSP 
environment,
   //   to initialize AP in InitConfig path.
@@ -1796,14 +1806,22 @@ MpInitLibInitialize (
   AsmGetAddressMap ();
   GetApResetVectorSize (, , 
);
   ApStackSize = PcdGet32 (PcdCpuApStackSize);
-  ApLoopMode  = GetApLoopMode ();
+  //
+  // ApStackSize must be power of 2
+  //
+  ASSERT ((ApStackSize & (ApStackSize - 1)) == 0);
+  ApLoopMode = GetApLoopMode ();
 
   //
   // Save BSP's Control registers for APs.
   //
   SaveVolatileRegisters ();
 
-  BufferSize  = ApStackSize * MaxLogicalProcessorNumber;
+  BufferSize = ApStackSize * MaxLogicalProcessorNumber;
+  //
+  // Allocate extra ApStackSize to let AP stack align on ApStackSize bounday
+  //
+  BufferSize += ApStackSize;
   BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber;
   BufferSize += ApResetVectorSizeBelow1Mb;
   BufferSize  = ALIGN_VALUE (BufferSize, 8);
@@ -1813,13 +1831,13 @@ MpInitLibInitialize (
   MpBuffer= AllocatePages (EFI_SIZE_TO_PAGES (BufferSize));
   ASSERT (MpBuffer != NULL);
   ZeroMem (MpBuffer, BufferSize);
-  Buffer = (UINTN)MpBuffer;
+  Buffer = ALIGN_VALUE ((UINTN)MpBuffer, ApStackSize);
 
   //
-  //  The layout of the Buffer is as below:
+  //  The layout of the Buffer is as below (lower address on top):
   //
-  //++ <-- Buffer
-  //AP Stacks (N)
+  //++ <-- Buffer (Pointer of CpuMpData is stored in 
the top of

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] [PATCH v3] DynamicTablesPkg: Add support to build _DSD

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in GetControllerName

[edk2-devel] [PATCH v2] OvmfPkg: Update I/O port related to ACPI devices for CloudHv

Re: [edk2-devel] [PATCH] OvmfPkg: Update I/O port related to ACPI devices for CloudHv

Re: [edk2-devel] [PATCH 2/2] Dynamic Tbl Mgr: MPAM: MPAM Generator and supporting files

Re: [edk2-devel] [PATCH 1/2] Mde Pkg: Support for MPAM ACPI Table

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Silicon/SynQuacer/PlatformDxe: set ACPI as default hardware description

[edk2-devel] [PATCH 2/2] CloudHv/arm: switch PeiMemLib to its own

[edk2-devel] [PATCH v2 1/2] CloudHv/arm: add PeiMemInfoLib

[edk2-devel] [PATCH v2 0/2] CloudHv/arm: Add specific mem info lib

Re: [edk2-devel] [PATCH V4 3/3] RedfishPkg: Redfish functions for REST requests are not fully spec complied

Re: [edk2-devel] [PATCH 1/2] CloudHv/arm: add PeiMemInfoLib

[edk2-devel] [PATCH edk2-platforms 1/1] Silicon/SynQuacer/PlatformDxe: set ACPI as default hardware description

[edk2-devel] [Patch V2] UefiCpuPkg: Use Top of each AP's stack to save CpuMpData

21 matches

Site Navigation

Mail list logo

Footer information