v2:
* Fix the ASSERT issue.
Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
we provide this patch to IPv6 condition check by leveraging AIP Protocol.
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karu
Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
we provide this patch to IPv6 condition check by leveraging AIP Protocol.
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P
Signed-off-by: Wu Ji
Base on the request of https://bugzilla.tianocore.org/show_bug.cgi?id=710,
we provide this patch to IPv6 condition check by leveraging AIP Protocol.
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Karunakar P
Signed-off-by: Wu Ji
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr
b/NetworkPkg/I
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
NetworkPkg/IScsiDxe/IScsiConfig.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
b/NetworkPkg/IScsiDxe/
The existing attempt should not trigger the DHCP process if it
doesn't associates with the current NIC. That's incorrect when
displaying the initiator info in attempt page.
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
Cc: Karunakar P
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
Jiaxin Wu (3):
NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process.
NetworkPkg/IScsiDxe: Clean the previous ConfigData when switching the IP mode.
NetworkPk
On Tue, Oct 17, 2017 at 09:54:04PM +0200, Laszlo Ersek wrote:
> On 10/17/17 21:16, Laszlo Ersek wrote:
> > Commit 53c6ff180327 ("SecurityPkg:AuthVariableLib:Implement ECR1707 for
> > Private Auth Variable", 2017-09-12) introduced the following build
> > failure under several GCC toolchain versions:
I do not think there is interface *change*.
We can define a *new* interface in MdeModulePkg\Include\Protocol.
Thank you
Yao Jiewen
From: Wang, Jian J
Sent: Wednesday, October 18, 2017 1:52 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric ; Kinney,
Michael D
Subject: RE:
Yes, we can. But that also means public interfaces changes, which might affect
internal/external users. Any formal procedure required to make such kind of
changes?
From: Yao, Jiewen
Sent: Wednesday, October 18, 2017 1:07 PM
To: Wang, Jian J ; edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric ;
This patch is to follow RFC3021 which allows to use 31-bit mask
in point-to-point link.
If a 31-bit subnet mask is assigned to a point-to-point link, it
leaves the with only 1 bit. Consequently, only two
possible addresses may result:
{, 0} and {, -1}
These addresses have historically been asso
Hi
I am a little worried about adding page table management in PiSmmCore directly.
Can we define an interface between PiSmmCore and PiSmmCpu driver to set memory
attribute? Like what we did in DxeCore and DxeCpu driver.
Thank you
Yao Jiewen
From: Wang, Jian J
Sent: Tuesday, October 17, 2017 9:2
The function HiiGetString will return NULL pointer when
the platform does not install the appropriate string or
call HiiGetString fail.(For example, HII not support specified
language.)
Cc: Zhang Chao
Cc: Wu Hao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: chenc2
---
Thanks. Then I think Paolo’s suggestion makes more sense.
If we can use same off, that would be great.
If no, just check AMD version ID in SaveState.
Thank you
Yao Jiewen
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Tuesday, October 17, 2017 11:15 PM
Laszlo,
I think the function name confused you.
MtrrLibApplyVariableMtrrs() is not to apply the MTRR setting to CPU/HW.
It's to apply the setting read from CPU/HW to the range array stored in memory.
It doesn't have side effect.
The basic idea of MtrrDebugPrintAllMtrrsWorker() is to read the setti
I missed the following, both while reviewing and while testing commit
6041ac65ae87 ("OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION
when SEV is active", 2017-10-05):
If "-D SECURE_BOOT_ENABLE" is not passed on the "build" command line, then
OVMF has no dynamic default at all for
"PcdOptio
The BuildEnv utility is sourced (executed by the user's interactive shell)
when the user sets up the build session. Some users like to set -C
(noclobber) for some additional safety in their shells, which trips up
BuildEnv. Update the redirection operator so that it overrides noclobber.
Cc: Liming
Hello everyone,
I am attempting to compile an EDK2 environment for UEFI on macOS Sierra 10.12.6
using Xcode 9.0.1 (developer tools installed). I have made the fix to the
build.sh file as outlined here:
https://lists.01.org/pipermail/edk2-devel/2017-June/011719.html , so that
XCODE5 is used, bu
On 10/17/17 21:16, Laszlo Ersek wrote:
> Commit 53c6ff180327 ("SecurityPkg:AuthVariableLib:Implement ECR1707 for
> Private Auth Variable", 2017-09-12) introduced the following build
> failure under several GCC toolchain versions:
>
>> SecurityPkg/Library/AuthVariableLib/AuthService.c: In function
On Tue, Oct 17, 2017 at 09:16:46PM +0200, Laszlo Ersek wrote:
> Commit 53c6ff180327 ("SecurityPkg:AuthVariableLib:Implement ECR1707 for
> Private Auth Variable", 2017-09-12) introduced the following build
> failure under several GCC toolchain versions:
>
> > SecurityPkg/Library/AuthVariableLib/Aut
On 10/05/17 22:16, Brijesh Singh wrote:
> By default the image verification policy for option ROM images is 0x4
> (DENY_EXECUTE_ON_SECURITY_VIOLATION) but the following OvmfPkg commit:
>
> 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot
>
> set it to 0x0 (ALWAYS_EXECUTE)
On 17 October 2017 at 20:16, Laszlo Ersek wrote:
> Commit 53c6ff180327 ("SecurityPkg:AuthVariableLib:Implement ECR1707 for
> Private Auth Variable", 2017-09-12) introduced the following build
> failure under several GCC toolchain versions:
>
>> SecurityPkg/Library/AuthVariableLib/AuthService.c: In
On 10/17/17 21:07, Zmuda, Wojciech wrote:
> Hi Laszlo,
>
>
> Thanks for this detailed explanation. I repeated the experiment with EBC
> interpreter included, this time stepping much further in the code, and I
> actually can see that with Secure Boot enabled the EFI_SECURITY_VIOLATION
> status
Commit 53c6ff180327 ("SecurityPkg:AuthVariableLib:Implement ECR1707 for
Private Auth Variable", 2017-09-12) introduced the following build
failure under several GCC toolchain versions:
> SecurityPkg/Library/AuthVariableLib/AuthService.c: In function
> 'CalculatePrivAuthVarSignChainSHA256Digest':
>
Hi Laszlo,
Thanks for this detailed explanation. I repeated the experiment with EBC
interpreter included, this time stepping much further in the code, and I
actually can see that with Secure Boot enabled the EFI_SECURITY_VIOLATION
status is propagated, which does not let the image to load. Wit
Thanks!
I'll take that as a Tested-by:.
Reviewed-by: Leif Lindholm
Pushed as 1727ed8024.
/
Leif
On Tue, Oct 17, 2017 at 03:05:36PM +, Alexei Fedorov wrote:
> Yes, system can be restarted properly with this patch.
>
>
> Alexei.
>
>
> From: Leif Lindho
On Mon, Oct 16, 2017 at 05:34:13PM +0100, Ard Biesheuvel wrote:
> The signed capsule update support added to the Overdrive platform in
> a recent patch inadvertently introduced a dependency on the external
> OpenSSL library, which many users may not have installed into their
> EDK2 tree by default.
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, October 17, 2017 10:15 AM
> To: Yao, Jiewen ; Duran, Leo
>
> Cc: edk2-devel@lists.01.org; Paolo Bonzini ; Ni,
> Ruiyu ; Kinney, Michael D
> ; Justen, Jordan L
> ; Gao, Liming
> Subject: Re: [PATCH v5 1
> -Original Message-
> From: Yao, Jiewen [mailto:jiewen@intel.com]
> Sent: Tuesday, October 17, 2017 9:51 AM
> To: Duran, Leo
> Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Paolo
> Bonzini ; Ni, Ruiyu ; Kinney,
> Michael D ; Justen, Jordan L
> ; Gao, Liming
> Subject: Re: [PATCH v5 1
On Tue, Oct 17, 2017 at 02:32:05PM +, Evan Lloyd wrote:
>
>
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: 13 October 2017 08:53
> > To: Evan Lloyd
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [PATCH 13/19] ArmPlatformPkg: HdLcd Remove
On 17 October 2017 at 16:05, Gao, Liming wrote:
> Ard:
> MdeModulePkg\Universal\Acpi\FirmwarePerformanceDataTableDxe depends on some
> status code to fill basic boot FPDT record in FPDT table. Those status codes
> are reported from DxeCore. For FPDT table, DxeCore must link the real report
>
On 17/10/2017 16:50, Duran, Leo wrote:
> To me,
> - This proposed library function seems appropriate in the context of CPU
> features (i..e, this is not a hack)
> - I'd argue having to save & restore 512 "unused" bytes per SMI is
> significant overheard that can be avoided.
Can it be measured,
On 10/17/17 16:50, Yao, Jiewen wrote:
> I think it is unnecessary. All intel CPU is using same offset. All amd CPU is
> using same offset. It can be identified easily by code.
> Adding a new API now is also an incompatible change because that requires all
> existing featurelib change to add a new
Ard:
MdeModulePkg\Universal\Acpi\FirmwarePerformanceDataTableDxe depends on some
status code to fill basic boot FPDT record in FPDT table. Those status codes
are reported from DxeCore. For FPDT table, DxeCore must link the real report
status code. It links DXE version library instance.
Thank
Yes, system can be restarted properly with this patch.
Alexei.
From: Leif Lindholm
Sent: 17 October 2017 15:00:24
To: Ard Biesheuvel; Alexei Fedorov
Cc: edk2-devel@lists.01.org; Sudeep Holla
Subject: Re: [PATCH edk2-platforms v2] Platform/ARM: use appropriate
R
I think it is unnecessary. All intel CPU is using same offset. All amd CPU is
using same offset. It can be identified easily by code.
Adding a new API now is also an incompatible change because that requires all
existing featurelib change to add a new API. We have lots of close source
platform u
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, October 17, 2017 9:37 AM
> To: Laszlo Ersek ; Duran, Leo ;
> edk2-devel@lists.01.org; Jiewen Yao
> Cc: Ruiyu Ni ; Michael D Kinney
> ; Jordan Justen ;
> Liming Gao
> Subject: Re: [PATCH v5 1/2] Uefi
On 17/10/2017 16:23, Laszlo Ersek wrote:
>> For the SRAM_SAVE_STATE_MAP_OFFSET:
>> I propose returning the value by a function in SmmCpuFeaturesLib...
> This has crossed my mind (superficially :) ), and I support your idea.
>
> Paolo, can you please comment?
I don't see a reason why AMD must use
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 13 October 2017 08:53
> To: Evan Lloyd
> Cc: edk2-devel@lists.01.org
> Subject: Re: [PATCH 13/19] ArmPlatformPkg: HdLcd Remove redundant Bpp
>
> On Tue, Sep 26, 2017 at 09:15:23PM +0100, evan.ll...@arm.c
On 10/17/17 16:19, Duran, Leo wrote:
> Yao, Lazlo, et al,
>
> For the SRAM_SAVE_STATE_MAP_OFFSET:
> I propose returning the value by a function in SmmCpuFeaturesLib...
This has crossed my mind (superficially :) ), and I support your idea.
Paolo, can you please comment?
Thanks!
Laszlo
> Here's
Yao, Lazlo, et al,
For the SRAM_SAVE_STATE_MAP_OFFSET:
I propose returning the value by a function in SmmCpuFeaturesLib... Here's the
rationale:
- The value is fixed per CPU architecture, so this qualifies as a CPU feature.
- The logic for CPU architecture detection would be in one place (e.g.,
On 17 October 2017 at 09:53, Long, Qin wrote:
> Agree. It's better to use CHAR8 directly.
>
Could we get this fixed please? The GCC build has been broken for two days now.
>
> From: Gary Lin [mailto:g...@suse.com]
> Sent: Tuesday, October 17, 2017 10:10 AM
> To: Zhang, Chao B
> Cc: edk2-devel@
Thanks.
Alexei, can you confirm that this addresses your concerns?
/
Leif
On Tue, Oct 17, 2017 at 02:42:05PM +0100, Ard Biesheuvel wrote:
> ResetSystemRuntimeDxe may be invoked by the OS at runtime, at which time
> it will attempt to call into ReportStatusCodeLib. If we use the default
> ver
On 17/10/17 14:42, Ard Biesheuvel wrote:
> ResetSystemRuntimeDxe may be invoked by the OS at runtime, at which time
> it will attempt to call into ReportStatusCodeLib. If we use the default
> version for DXE drivers, this will access data structures that are no
> longer there so switch to the spe
ResetSystemRuntimeDxe may be invoked by the OS at runtime, at which time
it will attempt to call into ReportStatusCodeLib. If we use the default
version for DXE drivers, this will access data structures that are no
longer there so switch to the special runtime version instead.
Contributed-under: T
Heap guard feature needs paging to work properly. 64-bit BIOS uses
PcdDxeIplBuildPageTables to control the page table setup. 32-bit BIOS
has to check heap guard feature to decide enabling paging or not.
Cc: Star Zeng
Cc: Eric Dong
Cc: Jiewen Yao
Suggested-by: Ayellet Wolman
Contributed-under:
> According to Eric's feedback:
> a. Enclose bit-or with parentheses
> b. Add code in 32-bit code to bypass setting page table to read-only
Heap guard feature will update page attributes frequently. The page table
should not set to be read-only if heap guard feature is enabled for SMM
mode. Otherw
Cc: Star Zeng
Cc: Eric Dong
Cc: Jiewen Yao
Suggested-by: Ayellet Wolman
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang
---
MdeModulePkg/MdeModulePkg.dec | 57 ++
MdeModulePkg/MdeModulePkg.uni | 58
> According to Eric's feedback:
> a. Remove local variable initializer with memory copy from globals
> b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
>message
> c. Remove unnecessary debug code
> d. Change name of function InitializePageTableLib to
>InitializePageTableGlo
> According to Eric's feedback:
> a. Remove local variable initializer with memory copy from globals
> b. Add comment for the use of mOnGuarding
> c. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
>message
>
> Other changes:
> d. Fix issues in 32-bit boot mode
> e. Remove protot
Heap guard feature will frequently update page attributes. The debug message
in CpuDxe driver will slow down the boot performance noticeably. Changing the
debug level to DEBUG_POOL and DEBUG_PAGE to reduce the message output for
normal debug configuration.
Cc: Eric Dong
Suggested-by: Ayellet Wolm
> Patch V2 changes:
> a. Remove local variable initializer with memory copy from globals
> b. Change map table dump code to use DEBUG_PAGE|DEBUG_POOL level
>message
> c. Fix malfunction in 32-bit boot mode
> d. Add comment for the use of mOnGuarding
> e. Change name of function InitializePageT
Edk2 has duplicated ping6/ifconfig6 implementation in NetworkPkg and ShellPkg.
The usage and parameter format of these 2 versions are exactly same. These two
commands have been added to Shell specification so the copy under
ShellPkg\Library\UefiShellNetwork2CommandsLib\
will be actively maintaine
Not sure that previous mail was delivered, Hence resending the same Mail.
Thanks,
Karunakar
-Original Message-
From: Karunakar P
Sent: Tuesday, October 17, 2017 3:43 PM
To: 'Wu, Jiaxin'; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan
Subject: RE: [edk2] [Patch 0/2] Add IPv6 support con
On 16/10/17 19:03, Ard Biesheuvel wrote:
> The generic ResetSystemRuntimeDxe may invoke ReportStatusCodeLib, and
> this may happen at runtime. If the chosen resolution is not suitable
> for runtime, this will result in a crash.
>
> Given that we don't actually use status codes, let's just switch
Hi Jiaxin,
I Reviewed the changes for 3 features/Bugs and verified the same, Please find
my below comments and issues faced
A. Display InitiatorInfo in attempt page even DHCP enabled
Agree. It's better to use CHAR8 directly.
From: Gary Lin [mailto:g...@suse.com]
Sent: Tuesday, October 17, 2017 10:10 AM
To: Zhang, Chao B
Cc: edk2-devel@lists.01.org; Long, Qin
Subject: Re: [edk2] [PATCH] SecurityPkg:AuthVariableLib:Fix GCC build error
On Mon, Oct 16, 2017 at 10:08:29PM +0800
On 17 October 2017 at 01:53, Gao, Liming wrote:
> Ard:
>
> MdeModulePkg\Library\RuntimeDxeReportStatusCodeLib\RuntimeDxeReportStatusCodeLib.inf
> is designed for Runtime driver. If you require StatusCode at runtime, you
> can use this library instance.
>
Thanks Liming.
I wrongly assumed tha
On 17 October 2017 at 09:41, Alexei Fedorov wrote:
> Ard,
>
>
> BaseReportStatusCodeLibNull.inf was replaced with DxeReportStatusCodeLib.inf
> to support storing boot performance data required for FPDT ACPI table.
>
> As Liming already mentioned ResetSystemRuntimeDxe.inf should be linked to
> Runt
Ard,
BaseReportStatusCodeLibNull.inf was replaced with DxeReportStatusCodeLib.inf to
support storing boot performance data required for FPDT ACPI table.
As Liming already mentioned ResetSystemRuntimeDxe.inf should be linked to
RuntimeDxeReportStatusCodeLib library:
MdeModulePkg/Universal/R
On 10/17/17 03:46, Ruiyu Ni wrote:
> ARRAY_SIZE(Mtrrs->Variables.Mtrr) was used in
> MtrrDebugPrintAllMtrrsWorker() to parse the MTRR registers.
> Instead, the actual variable MTRR count should be used.
> Otherwise, the uninitialized random data in MtrrSetting may cause
> MtrrLibSetMemoryType() han
61 matches
Mail list logo
