date:20160917

Re: [edk2] [PATCH] IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 Pkgs

2016-09-17 Thread Yao, Jiewen

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Satya Yarlagadda
> Sent: Saturday, September 17, 2016 11:25 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [edk2] [PATCH] IntelFsp2Pkg: Align #Pragma in UPD header files to
> rest of EDK2 Pkgs
> 
> Changed the GenCfgOpt.py script to insert pragma pack(1) instead of
> pragma pack (push, 1) in the upd header files generated during fsp build.
> This is to align with rest of the EDKII pkgs pragma pack usage.
> 
> Also, this scripts generates UnusedUpdSpace for UPD address gaps.
> Currently it uses UIN16/UINT32/UINT64 for 2/4/8 bytes instead of UINT8[],
> thus causing upd space waste to have Natural Alignment. Hence changed the
> script to use UINT8[] for any unusedUpd fields above 1 byte.
> 
> Cc: Maurice Ma 
> Cc: Jiewen Yao 
> Cc: Giri P Mudusuru 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Satya Yarlagadda 
> ---
>  IntelFsp2Pkg/Tools/GenCfgOpt.py | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/Tools/GenCfgOpt.py
> b/IntelFsp2Pkg/Tools/GenCfgOpt.py
> index e8cec95..654cdfc 100644
> --- a/IntelFsp2Pkg/Tools/GenCfgOpt.py
> +++ b/IntelFsp2Pkg/Tools/GenCfgOpt.py
> @@ -875,6 +875,9 @@ EndList
>  IsArray = False
>  if Length in [1,2,4,8]:
>  Type = "UINT%d" % (Length * 8)
> +if Name.startswith("UnusedUpdSpace") and Length != 1:
> +IsArray = True
> +Type = "UINT8"
>  else:
>  IsArray = True
>  Type = "UINT8"
> @@ -1129,7 +1132,7 @@ EndList
>  HeaderFd.write("#ifndef __%s__\n"   % FileName)
>  HeaderFd.write("#define __%s__\n\n" % FileName)
>  HeaderFd.write("#include <%s>\n\n" % HeaderFileName)
> -HeaderFd.write("#pragma pack(push, 1)\n\n")
> +HeaderFd.write("#pragma pack(1)\n\n")
> 
>  Export = False
>  for Line in IncLines:
> @@ -1177,7 +1180,7 @@ EndList
>  for Item in range(len(StructStart)):
>  if Index >= StructStartWithComment[Item] and
> Index <= StructEnd[Item]:
>  HeaderFd.write (Line)
> -HeaderFd.write("#pragma pack(pop)\n\n")
> +HeaderFd.write("#pragma pack()\n\n")
>  HeaderFd.write("#endif\n")
>  HeaderFd.close()
> 
> @@ -1188,7 +1191,7 @@ EndList
>  HeaderFd.write("#ifndef __%s__\n"   % FileName)
>  HeaderFd.write("#define __%s__\n\n" % FileName)
>  HeaderFd.write("#include \n\n")
> -HeaderFd.write("#pragma pack(push, 1)\n\n")
> +HeaderFd.write("#pragma pack(1)\n\n")
> 
>  for item in range(len(UpdRegionCheck)):
>  Index = 0
> @@ -1222,7 +1225,7 @@ EndList
>  for Item in range(len(StructStart)):
>  if Index >= StructStartWithComment[Item] and
> Index <= StructEnd[Item]:
>  HeaderFd.write (Line)
> -HeaderFd.write("#pragma pack(pop)\n\n")
> +HeaderFd.write("#pragma pack()\n\n")
>  HeaderFd.write("#endif\n")
>  HeaderFd.close()
> 
> --
> 2.10.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] edk2 compile error

2016-09-17 Thread Chen, Farrah

Hi,

When I compile xen with the latest commit in RHEL 6.7, it failed when make 
tools. Errors showed when running edk2 build for OvmfPkgX64.
Bisected and this error occurred from commit 
8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.

commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2
Author: Wei Liu >
Date:   Tue Sep 6 12:54:47 2016 +0100

Config.mk: update OVMF commit

Signed-off-by: Wei Liu wei.l...@citrix.com


We have updated OVMF to the latest master and cleaned everything before 
rebuilding.



Steps:

make clean

make xen -j8

./configure --enable-ovmf

make tools -j8

Then the error occurred.





I also tried:

git clone https://github.com/tianocore/edk2.git

cd edk2

OvmfPkg/build.sh -a X64 -b DEBUG -n 4
The same error occurred.
.

log:
..
Running edk2 build for OvmfPkgX64
..
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:173:
 error: invalid combination of opcode and operands
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:175:
 error: invalid combination of opcode and operands
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:177:
 error: invalid combination of opcode and operands
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:179:
 error: invalid combination of opcode and operands
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:313:
 error: invalid combination of opcode and operands
/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:315:
 error: invalid combination of opcode and operands
make[7]: Leaving directory 
`/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib'
make[7]: *** 
[/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.obj]
 Error 1


build.py...
: error 7000: Failed to execute command
make tbuild 
[/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib]


build.py...
: error F002: Failed to build module

/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
 [X64, GCC44, DEBUG]

- Failed -


Thanks,
Fan Chen


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RNG algo question

2016-09-17 Thread Ard Biesheuvel

On 16 September 2016 at 22:33, Palmer, Thomas  wrote:
>
> EDK2 community
>
> Why is the RngGetRNG  sending requests for "gEfiRngAlgorithmRaw"  to 
> "RdRandGenerateEntropy",  which does AES operations on RDRAND output, whereas 
> the requests for "gEfiRngAlgorithmSp80090Ctr256Guid" get sent to 
> RdRandGetBytes which simply reads the rdrand source without modification.
>
> Shouldn't the processing be switched, so that "Raw" goes to RdRandGetBytes 
> and "gEfiRngAlgorithmSp80090Ctr256Guid" goes to RdRandGenerateEntropy?  I did 
> not see anything in the UEFI 2.5 spec indicating why this was the case.
>

The RDRAND instruction does not give you raw entropy, but the output
of a DRBG. So the 'raw' entropy is being emulated by taking multiple
rounds of RDRAND output and shuffling it around to make it 'raw'

>From the top of RngDxe.c:

  RNG Algoritnms defined in UEFI 2.4:
   - EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID  - Supported
 (RDRAND implements a hardware NIST SP800-90 AES-CTR-256 based DRBG)
   - EFI_RNG_ALGORITHM_RAW- Supported
 (Structuring RDRAND invocation can be guaranteed as high-quality
entropy source)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] how big is the timer event overhead?

2016-09-17 Thread Michael Zimmermann

Hi,

if I add a timer with an interval of 1ms, how much will it affect the
system performance?
The callback only adds +1 to a global variable so I can keep track of the
total uptime without the need of a RTC.

Thanks
Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] how big is the timer event overhead?

2016-09-17 Thread Andrew Fish

> On Sep 17, 2016, at 8:13 AM, Michael Zimmermann  
> wrote:
> 
> Hi,
> 
> if I add a timer with an interval of 1ms, how much will it affect the
> system performance?
> The callback only adds +1 to a global variable so I can keep track of the
> total uptime without the need of a RTC.
> 

Michael,

In general the EFI Contract is you get at least the delay you asked for, but 
the quality of service is not guaranteed. The PI spec abstracts the system 
timer for the DXE Core via the Timer Architectural Protocol, 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Timer.h. 
The timers you request in EFI are software timers that are implemented using 
the Timer Protocol, but you are only going to get the quality of service of the 
Timer Period set by the Timer Protocol implementation (platform). You can query 
the period by calling GetTimerPeriod(). 

1st rule of performance tuning is to never assume how stuff works and always 
measure, that caveat aside here is conceptually what is going on.

EFI has an event driven model and it is cooperative (you could also argue it is 
a run to completion model) in that event functions exit to give control to 
other events. Events at equal to or less than TPL are blocked from running when 
an event is running at a given TPL (that is the run to completion bit). The 
cooperative bit is there is no scheduler, and there is only one thread and thus 
a common stack for the driver/application that is running and all the events. 
There is basically a queue, per TPL, of all the events that have been 
registered. This event queue is processed on calls to gBS->RestoreTPL() and any 
event that is a higher TPL than the restore can get called. Given the Timer 
tick is an interrupt it will raise to TPL_HIGH_LEVEL and then restore the TPL. 
This restoring of the TPL is what causes events to happen. 

So to  answer your question it kind of depends on your timer period and how 
many events you have as that is the time that is being stolen away from the 
driver/application that is running.  

If you are trying to measure elapsed time using a timer event is probably not a 
good way to do that since there is no scheduler the quality of service is not 
that good (the time between ticks will be no shorter than requested but could 
be longer). If your code is independent of the platform the Timestamp protocol 
may be useful for what you are doing 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Timestamp.h.
 Note it is newish so may not be on every platform. 

For code in the ROM that knows about the platform the TimerLib, 
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/TimerLib.h,
 is used for getting timing information. The combination of 
GetPerfomanceCounter(), GetPerfomanceCounterProperties(), and 
GetTimeInNanoSecond() can be used to do what you want I think. Generally on an 
X86 system this is the TSC, but figuring out the period of the TSC can be 
tricky if you don't know about your platform.

Thanks,

Andrew Fish

> Thanks
> Michael
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] RNG algo question

2016-09-17 Thread Long, Qin

Exactly. Thanks, Ard.

gEfiRngAlgorithmRaw is designed to provide entropy directly (defined in UEFI 
spec), which is intended to use the DRNG to seed in an ongoing manner some 
current software PRNG. Though RDRAND is quite usable as a source of random 
values. For standards compliance, some may feel it necessary to demand an 
absolute guarantee that values returned by RDRAND reflect independent entropy 
samples within the DRNG. One choice is to use RdSeed instruction directly. The 
current implementation leverage the reseeding guarantee of the DRBG to generate 
random seeds from values obtained via RDRAND (for the processor that do not 
support the RDSEED).
For gEfiRngAlgorithmSp80090Ctr256Guid, the current RdRand output is already 
compliant with NIST SP800-90C standards.

More information can be referred from 
https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide

Best Regards & Thanks,
LONG, Qin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Saturday, September 17, 2016 3:19 PM
To: Palmer, Thomas 
Cc: edk2-devel@lists.01.org; Gibbons, Pat 
Subject: Re: [edk2] RNG algo question

On 16 September 2016 at 22:33, Palmer, Thomas  wrote:
>
> EDK2 community
>
> Why is the RngGetRNG  sending requests for "gEfiRngAlgorithmRaw"  to 
> "RdRandGenerateEntropy",  which does AES operations on RDRAND output, whereas 
> the requests for "gEfiRngAlgorithmSp80090Ctr256Guid" get sent to 
> RdRandGetBytes which simply reads the rdrand source without modification.
>
> Shouldn't the processing be switched, so that "Raw" goes to RdRandGetBytes 
> and "gEfiRngAlgorithmSp80090Ctr256Guid" goes to RdRandGenerateEntropy?  I did 
> not see anything in the UEFI 2.5 spec indicating why this was the case.
>

The RDRAND instruction does not give you raw entropy, but the output of a DRBG. 
So the 'raw' entropy is being emulated by taking multiple rounds of RDRAND 
output and shuffling it around to make it 'raw'

>From the top of RngDxe.c:

  RNG Algoritnms defined in UEFI 2.4:
   - EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID  - Supported
 (RDRAND implements a hardware NIST SP800-90 AES-CTR-256 based DRBG)
   - EFI_RNG_ALGORITHM_RAW- Supported
 (Structuring RDRAND invocation can be guaranteed as high-quality entropy 
source) ___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelFsp2Pkg: Align #Pragma in UPD header files to rest of EDK2 Pkgs

[edk2] edk2 compile error

Re: [edk2] RNG algo question

[edk2] how big is the timer event overhead?

Re: [edk2] how big is the timer event overhead?

Re: [edk2] RNG algo question

6 matches

Site Navigation

Mail list logo

Footer information