答复: [edk2-devel] Patch List for 202008 stable tag

[gaoliming]

Laszlo:

> -邮件原件-
> 发件人: bounce+27952+64532+4905953+8761...@groups.io
> [mailto:bounce+27952+64532+4905953+8761...@groups.io] 代表 Laszlo
> Ersek
> 发送时间: 2020年8月21日 19:07
> 收件人: Gao, Liming ; Leif Lindholm
> ; af...@apple.com; Kinney, Michael D
> ; Guptha, Soumya K
> ; Chang, Abner (HPS SW/FW Technologist)
> ; Vladimir Olovyannikov
> ; Tom Lendacky
> 
> 抄送: devel@edk2.groups.io
> 主题: Re: [edk2-devel] Patch List for 202008 stable tag
> 
> On 08/20/20 13:30, Gao, Liming wrote:
> > Hi Stewards and all:
> >   I collect current patch lists in devel mail list. Those patch
contributors
> request to add them for 202008 stable tag. Because we have enter into Soft
> Feature Freeze, I want to collect your feedback for them. If any patches
are
> missing, please reply this mail to add them.
> >
> > Feature List:
> > https://edk2.groups.io/g/devel/message/63767 [PATCH]
> > EmbeddedPkg/libfdt: Add strncmp macro to use AsciiStrnCmp [Liming] This
> patch pass code review after Soft Feature Freeze (SFF) starts. According
to SFF
> definition, it should not be merged for this stable tag. But, the patch
submitter
> says this patch is important to RISC-V community. To catch it for this
stable tag,
> Laszlo proposed the solution to defer SFF start day from 2020-08-14 to
> 2020-08-21, then hard feature freeze and release date will also defer one
> week. Any patches those pass review before new SFF start day can be
merged.
> @ Stewards, please give your comments to defer this stable tag release by
> one week.
> 
> Thank you, very nice summary.
> 
> As stated earlier, I'm OK with 1 week (or even two weeks, if needed)
> extension. I invite Andrew, Leif and Mike to comment.
> 
[Liming] I don't see any other urgent request. I think it is enough to defer
1 week for this stable tag.
So far, there is objection for this defer. I will send the announcement
mail. 

> >
> > https://edk2.groups.io/g/devel/message/63348 [PATCH v5 1/1]
> > ShellPkg/DynamicCommand: add HttpDynamicCommand [Liming] This
> patch has collected the review comment. New version will be sent. I have
no
> information how important it is. @Vladimir, does this patch must catch
this
> stable tag? If yes, can you give the reason?
> 
> This is a feature addition. While it's a super useful feature, it needs to
mature
> (mainly from the coding style perspective, as I gather).
> Posting of new versions and review are on-going.
> 
> Most likely material for the next stable tag. In case we extend the
deadlines,
> and Maciej and the ShellPkg maintainers approve one of the upcoming
> versions until the new SFF, then yes, we can merge that too.
> 
[Liming] So, this is not urgent. Let's defer it to next stable tag. 

Thanks
Liming

> > Bug List:
> > https://edk2.groups.io/g/devel/message/64383 [PATCH 1/1]
> > UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable
[Liming]
> This patch has collected the review comment. New version will be sent.
> 
> This is a bugfix. Certainly a build fix on CLANGPDB. I tried to do some
> (lightweight) analysis to see whether the bug is a functional one as well
(i.e.
> whether the bad code path that CLANG warns about can actually occur in
> practice), but in the end I didn't want to spend much time on it, as the
build
> breakage needs to be fixed anyway.
> 
> So, this patch (more precisely, v2 of this patch) would even qualify
during the
> hard feature freeze (as it's clearly a bugfix).
> 
> >
> > https://edk2.groups.io/g/devel/message/50406 [PATCH 1/1]
> > MdePkg/Include: Add missing definitions of SMBIOS type 42h in SmBios.h
> [Liming] This patch passed review early. But, it is not merged. I will
merge it.
> 
> Right, it was approved on 2019-Nov-18. If it still applies cleanly, it
should be
> merged, before we enter the Hard Feature Freeze.
> 
> Well... now that I'm writing this, we have already entered the HFF (as
planned
> originally) and the patch doesn't seem to be upstream yet. So unless we
> extend, I don't think this patch qualifies.
> 
> (On the other hand -- it seems like we really should extend.)
> 
> Thanks!
> Laszlo
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64554): https://edk2.groups.io/g/devel/message/64554
Mute This Topic: https://groups.io/mt/76340919/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

答复: [edk2-devel] [PATCH] .pytool/EccCheck: Disable Ecc error code 10014 for open CI

[gaoliming]

Reviewed-by: Liming Gao 

> -邮件原件-
> 发件人: bounce+27952+64529+4905953+8761...@groups.io
> [mailto:bounce+27952+64529+4905953+8761...@groups.io] 代表 Zhang,
> Shenglei
> 发送时间: 2020年8月21日 16:46
> 收件人: devel@edk2.groups.io
> 抄送: Sean Brogan ; Bret Barkelew
> ; Michael D Kinney
> ; Liming Gao 
> 主题: [edk2-devel] [PATCH] .pytool/EccCheck: Disable Ecc error code 10014
> for open CI
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2920
> Ecc issues whose error code is 10014, can't be correctly handled under
Linux
> OS, resulting from a bug in Ecc tool.
> So we need to disable it before ecc tool is repaired.
> 
> Cc: Sean Brogan 
> Cc: Bret Barkelew 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Signed-off-by: Shenglei Zhang 
> ---
>  .pytool/Plugin/EccCheck/EccCheck.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.pytool/Plugin/EccCheck/EccCheck.py
> b/.pytool/Plugin/EccCheck/EccCheck.py
> index eee1ff7a77b5..3eaad0bf5623 100644
> --- a/.pytool/Plugin/EccCheck/EccCheck.py
> +++ b/.pytool/Plugin/EccCheck/EccCheck.py
> @@ -301,6 +301,7 @@ class EccCheck(ICiBuildPlugin):
>   "10011",
>   "10012",
>   "10013",
> + "10014", #need to be removed after
> BZ2904
> + is fixed
>   "10015",
>   "10016",
>   "10017",
> --
> 2.18.0.windows.1
> 
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64553): https://edk2.groups.io/g/devel/message/64553
Mute This Topic: https://groups.io/mt/76340818/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

答复: [edk2-devel] Patch List for 202008 stable tag

[gaoliming]

Sure. Seemly, this one is also missing. 

> -邮件原件-
> 发件人: bounce+27952+64541+4905953+8761...@groups.io
> [mailto:bounce+27952+64541+4905953+8761...@groups.io] 代表
> Vladimir Olovyannikov via groups.io
> 发送时间: 2020年8月22日 0:27
> 收件人: Gao, Liming ; Laszlo Ersek
> ; Tom Lendacky ; Leif
> Lindholm ; af...@apple.com; Kinney, Michael D
> ; Guptha, Soumya K
> ; Chang, Abner (HPS SW/FW Technologist)
> 
> 抄送: devel@edk2.groups.io
> 主题: Re: [edk2-devel] Patch List for 202008 stable tag
> 
> Hi Gao,
> 
> Can someone please also consider including this one?
> https://edk2.groups.io/g/devel/message/61938
> 
> It was reviewed, but then stuck in limbo for a couple of months.
> 
> Thank you,
> Vladimir
> 
> > -Original Message-
> > From: Laszlo Ersek 
> > Sent: Friday, August 21, 2020 4:10 AM
> > To: Vladimir Olovyannikov ; Gao,
> > Liming ; Tom Lendacky
> ;
> > Leif Lindholm ; af...@apple.com; Kinney, Michael D
> > ; Guptha, Soumya K
> > ; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Cc: devel@edk2.groups.io
> > Subject: Re: Patch List for 202008 stable tag
> >
> > On 08/20/20 17:41, Vladimir Olovyannikov wrote:
> >
> > > I am sending the revised patch set today. The patchset adds "http"
> > > command which works the same way as tftp. I am not sure how
> > > important it is, as this is an improvement, not a bug fix. When
> > > these are in, OvmfPkg/ArmVirtPkg will have this feature in as well.
> > > @Laszlo Laszlo, can you please add your comment?
> >
> > Expanding on what I said elsewhere in this thread, I'd like to confirm
> > that,
> > *whenever* the HTTP dynamic command is merged, the dependent
> > OvmfPkg/ArmVirtPkg patches can / should be merged too, as they have
> > been reviewed and test earlier, in the thread linked in the bugzilla
> > comment at
> >
> >   https://bugzilla.tianocore.org/show_bug.cgi?id=2857#c2
> >
> > Thanks
> > Laszlo
> 
> 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64552): https://edk2.groups.io/g/devel/message/64552
Mute This Topic: https://groups.io/mt/76340808/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] running CI locally

[Sean]

sorry.  In my last email I started typing at top and then moved inline 
and didn't delete my initial comments.  Please ignore the comments on 
top and look inline for details. :)


Thanks
Sean




On 8/21/2020 2:36 PM, Sean wrote:

Laszlo,



Idea being if the package supports host based unit tests it will scan 
package to make sure all host based unit tests and libraries are listed 
in the DSC.


As to why you see a different set of packages...that is interesting.  If 
you can include your full build logs i can look a little closer.  I know 
on the Azure CI servers we don't run the



On 8/21/2020 12:23 AM, Laszlo Ersek wrote:

Hi Mike, Sean;

On 08/19/20 19:59, Laszlo Ersek wrote:


I'll report back with more results.


I installed a Fedora 32 Server VM.

Installed the "mono-complete" package (+its deps).

Installed the "nodejs" package.

Installed "cspell" (+deps) with "npm" (with the latter coming from the
nodejs package).

Edk2 checked out at current HEAD
(5a6d764e1d073d28e8f398289ccb5592bf9a72ba).


* Platform CI results:

- :

   Built successfully for IA32, X64, and IA32X64 (toolchain: GCC5).

- :

   Built successfully for ARM and AARCH64 (toolchain: GCC5).


* Core CI results:

- 

   Complete run successful (toolchain: GCC5); no package / arch / target
   / test restrictions.

   I got the following WARNINGs:

   - ArmVirtPkg, EmulatorPkg, and OvmfPkg are covered by Platform CI, not
 Core CI -- these are expected:


PROGRESS - --Running ArmVirtPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running ArmVirtPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE



PROGRESS - --Running EmulatorPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running EmulatorPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE



PROGRESS - --Running OvmfPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running OvmfPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE


   - ArmVirtPkg, DynamicTablesPkg, CryptoPkg, EmulatorPkg, FatPkg,
 NetworkPkg, OvmfPkg, PcAtChipsetPkg, SecurityPkg and ShellPkg are
 not covered by host-based unit tests -- I think also expected:


PROGRESS - --Running ArmVirtPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT


PROGRESS - --Running DynamicTablesPkg: Host Unit Test Compiler Plugin 
NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT



PROGRESS - --Running CryptoPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT


PROGRESS - --Running EmulatorPkg: Host Unit Test Compiler Plugin 
NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT



PROGRESS - --Running FatPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT



PROGRESS - --Running NetworkPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT



PROGRESS - --Running OvmfPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT


PROGRESS - --Running PcAtChipsetPkg: Host Unit Test Compiler Plugin 
NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT


PROGRESS - --Running SecurityPkg: Host Unit Test Compiler Plugin 
NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT



PROGRESS - --Running ShellPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin 
NOOPT


   - I'm not really sure about the following warnings. They were emitted
 for a subset of the above packages. I read the docs at

 


 but I still don't understand :)


Each plugin/test has a readme as well.  Not sure if this helps explain 
the HostUnitTestDscCompleteCheck more.


https://github.com/tianocore/edk2/tree/master/.pytool/Plugin/HostUnitTestDscCompleteCheck 



As to why you don't see it skipped for ArmVirtPkg or a few others: I 
think this is a bug.


In Azure CI i see it as test passed.

PROGRESS - --Running ArmVirtPkg: Host Unit Test Dsc Complete Check Test 
NO-TARGET --
PROGRESS - --->Test Success: Host Unit Test Dsc Complete Check Test 
NO-TARGET


When i look at the code

Re: [edk2-devel] running CI locally

[Sean]

Laszlo,



Idea being if the package supports host based unit tests it will scan 
package to make sure all host based unit tests and libraries are listed 
in the DSC.


As to why you see a different set of packages...that is interesting.  If 
you can include your full build logs i can look a little closer.  I know 
on the Azure CI servers we don't run the



On 8/21/2020 12:23 AM, Laszlo Ersek wrote:

Hi Mike, Sean;

On 08/19/20 19:59, Laszlo Ersek wrote:


I'll report back with more results.


I installed a Fedora 32 Server VM.

Installed the "mono-complete" package (+its deps).

Installed the "nodejs" package.

Installed "cspell" (+deps) with "npm" (with the latter coming from the
nodejs package).

Edk2 checked out at current HEAD
(5a6d764e1d073d28e8f398289ccb5592bf9a72ba).


* Platform CI results:

- :

   Built successfully for IA32, X64, and IA32X64 (toolchain: GCC5).

- :

   Built successfully for ARM and AARCH64 (toolchain: GCC5).


* Core CI results:

- 

   Complete run successful (toolchain: GCC5); no package / arch / target
   / test restrictions.

   I got the following WARNINGs:

   - ArmVirtPkg, EmulatorPkg, and OvmfPkg are covered by Platform CI, not
 Core CI -- these are expected:


PROGRESS - --Running ArmVirtPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running ArmVirtPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE



PROGRESS - --Running EmulatorPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running EmulatorPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE



PROGRESS - --Running OvmfPkg: Compiler Plugin DEBUG --
WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
PROGRESS - --Running OvmfPkg: Compiler Plugin RELEASE --
WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE


   - ArmVirtPkg, DynamicTablesPkg, CryptoPkg, EmulatorPkg, FatPkg,
 NetworkPkg, OvmfPkg, PcAtChipsetPkg, SecurityPkg and ShellPkg are
 not covered by host-based unit tests -- I think also expected:


PROGRESS - --Running ArmVirtPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running DynamicTablesPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running CryptoPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running EmulatorPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running FatPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running NetworkPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running OvmfPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running PcAtChipsetPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running SecurityPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT



PROGRESS - --Running ShellPkg: Host Unit Test Compiler Plugin NOOPT --
WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT


   - I'm not really sure about the following warnings. They were emitted
 for a subset of the above packages. I read the docs at
 

 but I still don't understand :)


Each plugin/test has a readme as well.  Not sure if this helps explain 
the HostUnitTestDscCompleteCheck more.


https://github.com/tianocore/edk2/tree/master/.pytool/Plugin/HostUnitTestDscCompleteCheck

As to why you don't see it skipped for ArmVirtPkg or a few others: I 
think this is a bug.


In Azure CI i see it as test passed.

PROGRESS - --Running ArmVirtPkg: Host Unit Test Dsc Complete Check Test 
NO-TARGET --
PROGRESS - --->Test Success: Host Unit Test Dsc Complete Check Test 
NO-TARGET


When i look at the code
https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/HostUnitTestDscCompleteCheck/HostUnitTestDscCompleteCheck.py#L59

I see that how those packages *.ci.yaml have it configured is different 
than those that show skipped below.  It avoids the skip conditions but 
since those 

Re: [edk2-devel] [PATCH v3 0/6] Extend Last Attempt Status Usage

[Michael Kubacki]

Hi Sean,

Thanks for the feedback.

#1 - I will include both suggestions in v4.

Thanks,
Michael

On 8/20/2020 7:37 PM, Sean Brogan wrote:

Michael,

#1
I would suggest calling out the sub-range

0x10A0 | 0x17FF  -- Free for Library Implementations of FmpDevicePkg

I also might suggest splitting FmpDependencyLib and 
FmpDependencyCheckLib ranges just to show a consistent pattern of how 
each library instance within FmpDevicePkg gets a defined range.



#2
Given that edk2 does not have any real FmpDeviceLibs (only instance is 
FmpDevicePkg\Library\FmpDeviceLibNull\FmpDeviceLibNull.inf).  Now is the 
best time to make a breaking change. It is very common for downstream 
code repositories to integrate edk2 and be forced to make changes 
associated with the new integration.  To me this is preferred.  A build 
break is easy to resolve. When functionality changes or new features are 
added but don't cause a break this is more difficult to integrate 
correctly.  Not only that, it leads to nearly everyone ignoring the 
change.  There is no need for this change to be a multi-year integration 
or cause extra development of shims and translation functions.  The API 
change is pretty easy.  The implementation can choose to to avoid the 
new ranges and just set the value to 1 (FMP unknown error).  This would 
match the behavior of today.  Obviously i believe it would better to 
take the extra time to create unique ranges for each of your libs.  Also 
note that if anyone is doing third party binary integration this is not 
a breaking change.  This only breaks for those doing a src build.


Thanks
Sean






On 8/20/2020 6:25 PM, Michael Kubacki wrote:

Hi Mike,

1) Yes, we can certainly leave more of the unsuccessful vendor range 
available for future expansion. I believe we can also reduce the FMP 
reserved range. How about a length of 0x800 for both?


The ranges would then be defined as follows:

START | END   | Usage
--|
0x1000    | 0x17FF    | FmpDevicePkg  |
    0x1000 |    0x107F | FmpDxe driver |
    0x1080 |    0x109F | FMP dependencies (e.g. FmpDependencyLib)  |
0x1800    | 0x1FFF    | FmpDeviceLib instances implementation |
0x2000    | 0x3FFF    | Unused. Available for future expansion.   |

Also, I don't see a problem with removing the length defines and 
directly specifying min/max defines for each range.


2.) I understand the compatibility concern but as you noted it is 
cleaner to maintain a single interface. I believe making the 
transition to the new API will only become more difficult in the 
future as it may go unnoticed resulting in implementations that don't 
implement support for this capability leading to an increasing amount 
of future effort to do work that could be done now. Perhaps we could 
get thoughts from others as well?


3.) I will update these to return back an expected value.

Thanks,
Michael

On 8/19/2020 7:57 PM, Kinney, Michael D wrote:

Hi Michael,

A couple a couple general questions:

1) I see the entire range from 0x2000-0x3FFF is reserved for 
FmpDeviceLib.  If we
    every add more device/platform specific libs for FMP, there are 
no ranges available.
    Should we limit the FmpDeviceLib to a smaller range to support 
future expansion?


    Also, the style of LastAttemptStatus.h with extra defines for the 
length of
    each range is hard to read, and I do not think there are any 
consumers of the
    length defines from this public include file.  Since there are 
really only 3
    defined ranges, couldn't this be simplified to min/max defines 
for each range
    for a total of 6 #defines.  I do not expect ranges (once defined) 
to change in
    length, and the most that might happen in the future is adding 
new ranges for

    new lib classes in the unused ranges.

2) This series makes non-backwards compatible changes to some of the 
lib classes.
    I agree this is the cleanest way to add support for the vendor 
specific
    last attempt status.  It does mean that existing implementations 
will have
    to update their lib implementations to be compatible with this 
new version.
    I would be slightly cleaner to introduce new APIs with support 
for the
    vendor specific last attempt status codes.  Then update all libs 
to produce
    both the existing APIs and the new APIs (The old APIs can call 
the new APIs).
    Then update FmpDxe to use the new APIs.  This would be 3 patch 
series.

    If FmpDxe never calls the old APIs, then we could (at a future date)
    delete the old APIs from the lib class and the lib 
implementations could

    remove the old API that calls the new API.

3) The following APIs in the Null implementations have OUT params.
    Should these OUT params be set to an expected value?

  CheckFmpDependency()
  FmpDeviceGetImage()
  FmpDeviceSetImage()

Thanks,

Mike


-Original Message-
From: 

Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

[Michael Kubacki]

Hi Nate,

Yes, these are individual codes used within FmpDevicePkg. The specific 
error codes in the enum in v2 are not intended to be used outside 
FmpDevicePkg. I refactored this in v3.


What is desired is a way to consistently map error codes to specific 
error sources during the update flow. The codes might come from common 
FmpDevicePkg source code (like FmpDxe) or platform authored source code 
(like FmpDeviceLib). The exact codes used in FmpDevicePkg implementation 
do not necessarily need to be known to the library (it doesn't receive 
those as input) and the library is free to define codes for its own 
library instance implementation to use as output. For example, there 
might be cases where the FmpDxe driver and a FmpDeviceLib instance both 
define a similar error code (e.g. memory allocation failed) but the 
specific value leads to a particular error condition in either component.


At the moment, FmpDevicePkg implementation and FmpDeviceLib instances 
are the two high-level pieces involved in producing error codes so 
within the overall 0x1000 - 0x3FFF range available, they're each be 
assigned an overall range in the public header of length 0x800 (in v4) 
leaving 0x2000 for future expansion. In V3, this led to the ranges being 
defined in a public header but the specific error codes in the enum 
being defined in a private header.


Thanks,
Michael

On 8/20/2020 10:33 PM, Desimone, Nathaniel L wrote:

Hi Michael,

I guess I might not understand the exact use cases for the enum. It seems like 
the meaning of the error codes you only want to be known within FmpDevicePkg, 
but it appears to me that the error code values could traverse to drivers 
outside this package, is that correct?

Thanks,
Nate

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Tuesday, August 11, 2020 11:58 AM
To: Desimone, Nathaniel L ; devel@edk2.groups.io
Cc: Gao, Liming ; Kinney, Michael D ; 
Jiang, Guomin ; Xu, Wei6 
Subject: Re: [edk2-devel] [PATCH v2 2/6] FmpDevicePkg: Add LastAttemptStatus.h

I realized there is room for misinterpretation of the macros 
LAST_ATTEMPT_STATUS_DRIVER_ERROR_COUNT and 
LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_COUNT based on name.

If there's no further feedback on the topic, I'll change them to 
LAST_ATTEMPT_STATUS_DRIVER_ERROR_RANGE_LENGTH and 
LAST_ATTEMPT_STATUS_DEPENDENCY_ERROR_RANGE_LENGTH.

Thanks,
Michael

On 8/11/2020 10:46 AM, Michael Kubacki wrote:

#1: In v3, I'm going to split it such that the defines are in the
public header and the enum specifying the internal driver and
dependency ranges are in a private header to FmpDevicePkg.

Here's the current set of v3 changes to agree upon before sending a series:
1. Move the defines for the ranges to a public header 2. Move the enum
to a private instance file 3. Rename
LAST_ATTEMPT_STATUS_LIBRARY_ERROR_MIN_ERROR_CODE to
LAST_ATTEMPT_STATUS_DEVICE_LIBRARY_ERROR_MIN_ERROR_CODE
4. Include a comment to explicitly state new codes within a given
range must be added at the end of the range

Please let me know if there's any further feedback.

Thanks,
Michael

On 8/10/2020 5:31 PM, Desimone, Nathaniel L wrote:

My feedback:

#1: Why is LastAttemptStatus.h in PrivateInclude? Seems like
something you would want to have as a public header.

#2: If someone inserts a new enum value in the middle of
LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST it will make it difficult to
decode error codes in the future. Either put a comment that new error
code should go on the bottom. Or add some space between each entry
using something like this:

enum LAST_ATTEMPT_STATUS_EXPANDED_ERROR_LIST
{
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_GET_FMP_HEADER =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_PROGRESS_CALLBACK_ERROR =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 10,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_CHECK_POWER_API =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 20,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_CHECK_SYS_THERMAL_API =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 30,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_THERMAL =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 40,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_CHECK_SYS_ENV_API =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 50,
    LAST_ATTEMPT_STATUS_DRIVER_ERROR_SYSTEM_ENV =
LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL_VENDOR_RANGE_MIN + 60,

Then you can insert something in the middle by adding +5.

Thanks,
Nate

On 8/10/20, 1:28 PM, "devel@edk2.groups.io on behalf of Michael
Kubacki"  wrote:

  From: Michael Kubacki 

  Introduces a header file to contain Last Attempt Status codes
that
  define granular FmpDevicePkg usage of the UEFI Specification
  defined vendor range. The vendor range is described in UEFI
  Specification 2.8A section 23.4.

  With this change, FmpDevicePkg currently defines three subranges
of
  the Last Attempt Status vendor 

[edk2-devel] [edk2-staging/EdkRepo] [PATCH v2] EdkRepo: Return exit codes in edkrepo_entry_point.py

[Ashley E Desimone]

Return the error codes generated by edkrepo_cli that
is called in main()

Cc: Nate DeSimone 
Cc: Puja Pandya 
Cc: Bret Barkelew 
Cc: Prince Agyeman 
Cc: Erik Bjorge 
Signed-off-by: Ashley E Desimone 
---
 edkrepo/edkrepo_entry_point.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/edkrepo/edkrepo_entry_point.py b/edkrepo/edkrepo_entry_point.py
index c2ff56a..f759022 100644
--- a/edkrepo/edkrepo_entry_point.py
+++ b/edkrepo/edkrepo_entry_point.py
@@ -91,12 +91,12 @@ def main():
 try:
 mod = importlib.import_module(pref_entry)
 func = getattr(mod, pref_entry_func)
-func()
+return(func())
 except Exception as e:
 print('Unable to launch preferred entry point. Launching default entry 
point edkrepo.edkrepo_cli.py')
 traceback.print_exc()
 import edkrepo.edkrepo_cli
-edkrepo.edkrepo_cli.main()
+return(edkrepo.edkrepo_cli.main())
 
 if __name__ == "__main__":
 try:
-- 
2.26.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64547): https://edk2.groups.io/g/devel/message/64547
Mute This Topic: https://groups.io/mt/76336705/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] EdkRepo: Return exit codes in edkrepo_entry_point.py

[Ashley E Desimone]

Return the error codes generated by edkrepo_cli that
is called in main()

Cc: Nate DeSimone 
Cc: Puja Pandya 
Cc: Bret Barkelew 
Cc: Prince Agyeman 
Cc: Erik Bjorge 
Signed-off-by: Ashley E Desimone 
---
 edkrepo/edkrepo_entry_point.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/edkrepo/edkrepo_entry_point.py b/edkrepo/edkrepo_entry_point.py
index c2ff56a..f759022 100644
--- a/edkrepo/edkrepo_entry_point.py
+++ b/edkrepo/edkrepo_entry_point.py
@@ -91,12 +91,12 @@ def main():
 try:
 mod = importlib.import_module(pref_entry)
 func = getattr(mod, pref_entry_func)
-func()
+return(func())
 except Exception as e:
 print('Unable to launch preferred entry point. Launching default entry 
point edkrepo.edkrepo_cli.py')
 traceback.print_exc()
 import edkrepo.edkrepo_cli
-edkrepo.edkrepo_cli.main()
+return(edkrepo.edkrepo_cli.main())
 
 if __name__ == "__main__":
 try:
-- 
2.26.2.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64546): https://edk2.groups.io/g/devel/message/64546
Mute This Topic: https://groups.io/mt/76336622/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms] [PATCH v2] SgiPkg/RdN1EdgeX2: Add missing reference to PcdChipCount

[Vijayenthiran Subramaniam]

Commit e8fe2026dd79 (“Platform/ARM/SgiPkg: Use chip count constant on
rdn1edgex2 platform”) used the PcdChipCount constant but did not declare
its use in the ACPI table module. Fix this by listing it in the list of
PCDs to be looked up.

Signed-off-by: Vijayenthiran Subramaniam 
---

Changes since v1:
  - Add commit id in commit message for which this patch fixes the build
failure.

 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
index 974d9db543..d44f02ab0c 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
@@ -45,6 +45,8 @@
   gArmSgiTokenSpaceGuid.PcdDramBlock2Base
   gArmSgiTokenSpaceGuid.PcdDramBlock2Size
 
+  gArmSgiTokenSpaceGuid.PcdChipCount
+
   gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
   gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
   gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64545): https://edk2.groups.io/g/devel/message/64545
Mute This Topic: https://groups.io/mt/76333625/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SgiPkg: Add chip count PCD to build information file for rdn1edgex2

[Vijayenthiran Subramaniam]

Hi Leif,

On Thu, Aug 20, 2020 at 10:00 AM Leif Lindholm  wrote:
>
> On Wed, Aug 19, 2020 at 20:23:43 +0530, Vijayenthiran Subramaniam wrote:
> > PcdChipCount constant is used to define the maximum number chips
> > included in the multi-chip configuration. Add this constant to the
> > RDN1EdgeX2 ACPI tables build information (INF) file to allow this
> > constant to be used in the RDN1EdgeX2 ACPI tables.
>
> This patch fixes a build failure, the commit message should say so,
> and refer to which commit it fixes.
>

Okay, I will do that.

> Also, this fixes a build failure introduced 3.5 months ago, and no one
> noticed until now. Are we sure this platform belongs upstream?
>

This was noticed after the patch was merged upstream. This probably
slipped through during the patch rework and rebase. This was fixed
outside of the upstream code but missed to get this merged upstream.

Regards,
Vijayenthiran

> /
> Leif
>
> > Signed-off-by: Vijayenthiran Subramaniam 
> > ---
> >  Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf 
> > b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > index 974d9db543..d44f02ab0c 100644
> > --- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > +++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > @@ -45,6 +45,8 @@
> >gArmSgiTokenSpaceGuid.PcdDramBlock2Base
> >gArmSgiTokenSpaceGuid.PcdDramBlock2Size
> >
> > +  gArmSgiTokenSpaceGuid.PcdChipCount
> > +
> >gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
> >gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
> >gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
> > --
> > 2.17.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64544): https://edk2.groups.io/g/devel/message/64544
Mute This Topic: https://groups.io/mt/76288010/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SgiPkg: Add chip count PCD to build information file for rdn1edgex2

[Vijay S]

Hi Leif

On Thu, Aug 20, 2020 at 10:00 AM Leif Lindholm  wrote:
>
> On Wed, Aug 19, 2020 at 20:23:43 +0530, Vijayenthiran Subramaniam wrote:
> > PcdChipCount constant is used to define the maximum number chips
> > included in the multi-chip configuration. Add this constant to the
> > RDN1EdgeX2 ACPI tables build information (INF) file to allow this
> > constant to be used in the RDN1EdgeX2 ACPI tables.
>
> This patch fixes a build failure, the commit message should say so,
> and refer to which commit it fixes.
>

Okay, I will do that.

> Also, this fixes a build failure introduced 3.5 months ago, and no one
> noticed until now. Are we sure this platform belongs upstream?

This was noticed after the patch was merged upstream. This probably
slipped through during the patch rework and rebase. This was fixed
outside of the upstream code but missed to get this merged upstream.

Regards,
Vijayenthiran

>
> /
> Leif
>
> > Signed-off-by: Vijayenthiran Subramaniam 
> > ---
> >  Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf 
> > b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > index 974d9db543..d44f02ab0c 100644
> > --- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > +++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf
> > @@ -45,6 +45,8 @@
> >gArmSgiTokenSpaceGuid.PcdDramBlock2Base
> >gArmSgiTokenSpaceGuid.PcdDramBlock2Size
> >
> > +  gArmSgiTokenSpaceGuid.PcdChipCount
> > +
> >gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
> >gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
> >gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
> > --
> > 2.17.1
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64543): https://edk2.groups.io/g/devel/message/64543
Mute This Topic: https://groups.io/mt/76288010/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

[Michael D Kinney]

Reviewed-by: Michael D Kinney 

> -Original Message-
> From: Liming Gao 
> Sent: Friday, August 21, 2020 7:50 AM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Laszlo Ersek ; Leif 
> Lindholm ; Kinney, Michael D
> 
> Subject: [PATCH] Maintainers.txt: Update Liming mail address
> 
> Signed-off-by: Liming Gao 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> ---
>  Maintainers.txt | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index f673ddd2b3..57cd2fc662 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -80,7 +80,7 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/Security
>  EDK II Releases:
>  
>  W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
> -M: Liming Gao 
> +M: Liming Gao 
> 
>  UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
>  ---
> @@ -105,12 +105,12 @@ F: .azurepipelines/
>  M: Sean Brogan 
>  M: Bret Barkelew 
>  R: Michael D Kinney 
> -R: Liming Gao 
> +R: Liming Gao 
> 
>  .mergify/
>  F: .mergify/
>  M: Michael D Kinney 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Sean Brogan 
>  R: Bret Barkelew 
> 
> @@ -119,7 +119,7 @@ F: .pytool/
>  M: Sean Brogan 
>  M: Bret Barkelew 
>  R: Michael D Kinney 
> -R: Liming Gao 
> +R: Liming Gao 
> 
>  EDK II Packages:
>  
> @@ -156,7 +156,7 @@ BaseTools
>  F: BaseTools/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
>  M: Bob Feng 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Yuwei Chen 
> 
>  CryptoPkg
> @@ -197,7 +197,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
>  FmpDevicePkg
>  F: FmpDevicePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
> -M: Liming Gao 
> +M: Liming Gao 
>  M: Michael D Kinney 
>  R: Guomin Jiang 
>  R: Wei6 Xu 
> @@ -226,7 +226,7 @@ MdeModulePkg: ACPI modules
>  F: MdeModulePkg/Include/*Acpi*.h
>  F: MdeModulePkg/Universal/Acpi/
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
> 
>  MdeModulePkg: ACPI modules related to S3
>  F: MdeModulePkg/*LockBox*/
> @@ -288,7 +288,7 @@ F: MdeModulePkg/Universal/PCD/
>  F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
>  F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
> 
>  MdeModulePkg: Device and Peripheral modules
>  F: MdeModulePkg/*PciHostBridge*/
> @@ -327,7 +327,7 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
>  F: MdeModulePkg/Library/FmpAuthenticationLibNull/
>  F: MdeModulePkg/Universal/Esrt*/
>  R: Hao A Wu 
> -R: Liming Gao 
> +R: Liming Gao 
>  R: Guomin Jiang 
> 
>  MdeModulePkg: HII and UI modules
> @@ -358,7 +358,7 @@ R: Ray Ni 
>  MdeModulePkg: Pei Core
>  F: MdeModulePkg/Core/Pei/
>  R: Dandan Bi 
> -R: Liming Gao 
> +R: Liming Gao 
>  R: Debkumar De 
>  R: Harry Han 
>  R: Catharine West 
> @@ -390,13 +390,13 @@ F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
>  F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
>  F: MdeModulePkg/Universal/FaultTolerantWrite*/
>  R: Hao A Wu 
> -R: Liming Gao 
> +R: Liming Gao 
> 
>  MdePkg
>  F: MdePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
>  M: Michael D Kinney 
> -M: Liming Gao 
> +M: Liming Gao 
>  R: Zhiguang Liu 
> 
>  NetworkPkg
> --
> 2.27.0.windows.1
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64542): https://edk2.groups.io/g/devel/message/64542
Mute This Topic: https://groups.io/mt/76332353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Patch List for 202008 stable tag

[Vladimir Olovyannikov via groups.io]

Hi Gao,

Can someone please also consider including this one?
https://edk2.groups.io/g/devel/message/61938

It was reviewed, but then stuck in limbo for a couple of months.

Thank you,
Vladimir

> -Original Message-
> From: Laszlo Ersek 
> Sent: Friday, August 21, 2020 4:10 AM
> To: Vladimir Olovyannikov ; Gao,
> Liming ; Tom Lendacky
> ; Leif Lindholm ;
> af...@apple.com; Kinney, Michael D ;
> Guptha, Soumya K ; Chang, Abner (HPS
> SW/FW Technologist) 
> Cc: devel@edk2.groups.io
> Subject: Re: Patch List for 202008 stable tag
>
> On 08/20/20 17:41, Vladimir Olovyannikov wrote:
>
> > I am sending the revised patch set today. The patchset adds "http"
> > command which works the same way as tftp. I am not sure how important
> > it is, as this is an improvement, not a bug fix. When these are in,
> > OvmfPkg/ArmVirtPkg will have this feature in as well. @Laszlo Laszlo,
> > can you please add your comment?
>
> Expanding on what I said elsewhere in this thread, I'd like to confirm
> that,
> *whenever* the HTTP dynamic command is merged, the dependent
> OvmfPkg/ArmVirtPkg patches can / should be merged too, as they have
> been reviewed and test earlier, in the thread linked in the bugzilla
> comment
> at
>
>   https://bugzilla.tianocore.org/show_bug.cgi?id=2857#c2
>
> Thanks
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64541): https://edk2.groups.io/g/devel/message/64541
Mute This Topic: https://groups.io/mt/76306021/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] Maintainers.txt: Update Liming mail address

[gaoliming]

Signed-off-by: Liming Gao 
Cc: Andrew Fish 
Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Michael D Kinney 
---
 Maintainers.txt | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index f673ddd2b3..57cd2fc662 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -80,7 +80,7 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/Security
 EDK II Releases:
 
 W: 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
-M: Liming Gao 
+M: Liming Gao 
 
 UEFI Shell Binaries (ShellBinPkg.zip) from EDK II Releases:
 ---
@@ -105,12 +105,12 @@ F: .azurepipelines/
 M: Sean Brogan 
 M: Bret Barkelew 
 R: Michael D Kinney 
-R: Liming Gao 
+R: Liming Gao 
 
 .mergify/
 F: .mergify/
 M: Michael D Kinney 
-M: Liming Gao 
+M: Liming Gao 
 R: Sean Brogan 
 R: Bret Barkelew 
 
@@ -119,7 +119,7 @@ F: .pytool/
 M: Sean Brogan 
 M: Bret Barkelew 
 R: Michael D Kinney 
-R: Liming Gao 
+R: Liming Gao 
 
 EDK II Packages:
 
@@ -156,7 +156,7 @@ BaseTools
 F: BaseTools/
 W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
 M: Bob Feng 
-M: Liming Gao 
+M: Liming Gao 
 R: Yuwei Chen 
 
 CryptoPkg
@@ -197,7 +197,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git
 FmpDevicePkg
 F: FmpDevicePkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
-M: Liming Gao 
+M: Liming Gao 
 M: Michael D Kinney 
 R: Guomin Jiang 
 R: Wei6 Xu 
@@ -226,7 +226,7 @@ MdeModulePkg: ACPI modules
 F: MdeModulePkg/Include/*Acpi*.h
 F: MdeModulePkg/Universal/Acpi/
 R: Dandan Bi 
-R: Liming Gao 
+R: Liming Gao 
 
 MdeModulePkg: ACPI modules related to S3
 F: MdeModulePkg/*LockBox*/
@@ -288,7 +288,7 @@ F: MdeModulePkg/Universal/PCD/
 F: MdeModulePkg/Universal/PlatformDriOverrideDxe/
 F: MdeModulePkg/Universal/SecurityStubDxe/SecurityStub.c
 R: Dandan Bi 
-R: Liming Gao 
+R: Liming Gao 
 
 MdeModulePkg: Device and Peripheral modules
 F: MdeModulePkg/*PciHostBridge*/
@@ -327,7 +327,7 @@ F: MdeModulePkg/Library/DisplayUpdateProgressLib*/
 F: MdeModulePkg/Library/FmpAuthenticationLibNull/
 F: MdeModulePkg/Universal/Esrt*/
 R: Hao A Wu 
-R: Liming Gao 
+R: Liming Gao 
 R: Guomin Jiang 
 
 MdeModulePkg: HII and UI modules
@@ -358,7 +358,7 @@ R: Ray Ni 
 MdeModulePkg: Pei Core
 F: MdeModulePkg/Core/Pei/
 R: Dandan Bi 
-R: Liming Gao 
+R: Liming Gao 
 R: Debkumar De 
 R: Harry Han 
 R: Catharine West 
@@ -390,13 +390,13 @@ F: MdeModulePkg/Include/Guid/SystemNvDataGuid.h
 F: MdeModulePkg/Include/Protocol/SwapAddressRange.h
 F: MdeModulePkg/Universal/FaultTolerantWrite*/
 R: Hao A Wu 
-R: Liming Gao 
+R: Liming Gao 
 
 MdePkg
 F: MdePkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/MdePkg
 M: Michael D Kinney 
-M: Liming Gao 
+M: Liming Gao 
 R: Zhiguang Liu 
 
 NetworkPkg
-- 
2.27.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64539): https://edk2.groups.io/g/devel/message/64539
Mute This Topic: https://groups.io/mt/76332353/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v6 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Introduce an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must
be set to TRUE.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

Signed-off-by: Vladimir Olovyannikov 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 
---
 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 .../HttpDynamicCommand/HttpApp.inf|   58 +
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   88 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1693 +
 .../HttpDynamicCommand/HttpApp.c  |   61 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
 CryptoPkg/Library/OpensslLib/openssl  |2 +-
 .../HttpDynamicCommand/Http.uni   |  116 ++
 11 files changed, 2228 insertions(+), 1 deletion(-)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni

diff --git a/ShellPkg/ShellPkg.dec b/ShellPkg/ShellPkg.dec
index d0843d338126..7b2d1230bd2c 100644
--- a/ShellPkg/ShellPkg.dec
+++ b/ShellPkg/ShellPkg.dec
@@ -53,6 +53,7 @@ [Guids]
   gShellNetwork1HiiGuid   = {0xf3d301bb, 0xf4a5, 0x45a8, {0xb0, 0xb7, 
0xfa, 0x99, 0x9c, 0x62, 0x37, 0xae}}
   gShellNetwork2HiiGuid   = {0x174b2b5, 0xf505, 0x4b12, {0xaa, 0x60, 
0x59, 0xdf, 0xf8, 0xd6, 0xea, 0x37}}
   gShellTftpHiiGuid   = {0x738a9314, 0x82c1, 0x4592, {0x8f, 0xf7, 
0xc1, 0xbd, 0xf1, 0xb2, 0x0e, 0xd4}}
+  gShellHttpHiiGuid   = {0x390f84b3, 0x221c, 0x4d9e, {0xb5, 0x06, 
0x6d, 0xb9, 0x42, 0x3e, 0x0a, 0x7e}}
   gShellBcfgHiiGuid   = {0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 
0xeb, 0x12, 0xda, 0xb4, 0xa2, 0xb6}}
   gShellAcpiViewHiiGuid   = {0xda8ccdf4, 0xed8f, 0x4ffc, {0xb5, 0xef, 
0x2e, 0xf5, 0x5e, 0x24, 0x93, 0x2a}}
   # FILE_GUID as defined in ShellPkg/Application/Shell/Shell.inf
diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
index 86e9f1e0040d..c42bc9464a0f 100644
--- a/ShellPkg/ShellPkg.dsc
+++ b/ShellPkg/ShellPkg.dsc
@@ -139,6 +139,11 @@ [Components]
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   }
   ShellPkg/DynamicCommand/TftpDynamicCommand/TftpApp.inf
+  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf {
+
+  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
+  }
+  ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
   ShellPkg/DynamicCommand/DpDynamicCommand/DpDynamicCommand.inf {
 
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
diff --git a/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf 
b/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
new file mode 100644
index ..d08d47fb37d5
--- /dev/null
+++ b/ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
@@ -0,0 +1,58 @@
+##  @file
+# Provides Shell 'http' standalone application.
+#
+# Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved. 
+# Copyright (c) 2015, ARM Ltd. All rights reserved.
+# Copyright (c) 2020, Broadcom. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010006
+  BASE_NAME  = http
+  FILE_GUID  = 56B00FB7-91D2-869B-CE5C-26CD1A89C73C
+  MODULE_TYPE= UEFI_APPLICATION
+  VERSION_STRING = 1.0
+  ENTRY_POINT= HttpAppInitialize
+#
+#  This flag specifies whether HII resource section is generated into PE image.
+#
+  UEFI_HII_RESOURCE_SECTION  = TRUE
+
+[Sources.common]
+  Http.c
+  HttpApp.c
+  Http.h
+  Http.uni
+
+[Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  NetworkPkg/NetworkPkg.dec
+  ShellPkg/ShellPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  FileHandleLib
+  HiiLib
+  HttpLib
+  MemoryAllocationLib
+  NetLib
+  ShellLib
+  UefiApplicationEntryPoint
+  UefiBootServicesTableLib
+  

[edk2-devel] [PATCH v6 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

[Vladimir Olovyannikov via groups.io]

Signed-off-by: Vladimir Olovyannikov 
Cc: Zhichao Gao 
Cc: Maciej Rabeda 
Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Nd 
Cc: Laszlo Ersek 
Cc: Samer El-Haj-Mahmoud 

This patchset introduces an http client utilizing EDK2 HTTP protocol, to
allow fast image downloading from http/https servers.
HTTP download speed is usually faster than tftp.
The client is based on the same approach as tftp dynamic command, and
uses the same UEFI Shell command line parameters. This makes it easy
integrating http into existing UEFI Shell scripts.
Note that to enable HTTP download, feature Pcd
gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections must be set to TRUE.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2860

PATCH v6 changes:
Address Laszlo' and Maciej's comments:
  - adjusted code to comply with EDK2 code style;
  - replaced multiple ShellPrintHiiEx calls with appropriate macros
for better readability
  - refactored TrimSpaces() to avoid multiple CopyMem() calls.

Vladimir Olovyannikov (1):
  ShellPkg/DynamicCommand: add HttpDynamicCommand

 ShellPkg/ShellPkg.dec |1 +
 ShellPkg/ShellPkg.dsc |5 +
 .../HttpDynamicCommand/HttpApp.inf|   58 +
 .../HttpDynamicCommand/HttpDynamicCommand.inf |   63 +
 .../DynamicCommand/HttpDynamicCommand/Http.h  |   88 +
 ShellPkg/Include/Guid/ShellLibHiiGuid.h   |5 +
 .../DynamicCommand/HttpDynamicCommand/Http.c  | 1693 +
 .../HttpDynamicCommand/HttpApp.c  |   61 +
 .../HttpDynamicCommand/HttpDynamicCommand.c   |  137 ++
 CryptoPkg/Library/OpensslLib/openssl  |2 +-
 .../HttpDynamicCommand/Http.uni   |  116 ++
 11 files changed, 2228 insertions(+), 1 deletion(-)
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.inf
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.inf
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.h
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/HttpApp.c
 create mode 100644 
ShellPkg/DynamicCommand/HttpDynamicCommand/HttpDynamicCommand.c
 create mode 100644 ShellPkg/DynamicCommand/HttpDynamicCommand/Http.uni

--
2.26.2.266.ge870325ee8


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64537): https://edk2.groups.io/g/devel/message/64537
Mute This Topic: https://groups.io/mt/76332037/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/SmmControl2Dxe: negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG

[Laszlo Ersek]

Hi Ard,

can you please ACK this patch?

I'm not (necessarily) aiming at the upcoming stable tag, but Igor has
resumed work on the QEMU-side patches [*], so this is again relevant for
edk2.

[*] http://mid.mail-archive.com/20200818122208.1243901-1-imammedo@redhat.com
https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg03892.html

(Top-posting because I want to keep the full context intact for you.)

Thanks!
Laszlo

On 07/14/20 20:43, Laszlo Ersek wrote:
> The ICH9_LPC_SMI_F_BROADCAST and ICH9_LPC_SMI_F_CPU_HOTPLUG feature flags
> cause QEMU to behave as follows:
> 
>   BROADCAST  CPU_HOTPLUG  use case / behavior
>   -  ---  
>   clear  clearOVMF built without SMM_REQUIRE; or very old OVMF
>   (from before commit a316d7ac91d3 / 2017-02-07).
>   QEMU permits CPU hotplug operations, and does
>   not cause the OS to inject an SMI upon hotplug.
>   Firmware is not expected to be aware of hotplug
>   events.
> 
>   clear  set  Invalid feature set; QEMU rejects the feature
>   negotiation.
> 
>   setclearOVMF after a316d7ac91d3 / 2017-02-07, built with
>   SMM_REQUIRE, but no support for CPU hotplug.
>   QEMU gracefully refuses hotplug operations.
> 
>   setset  OVMF after a316d7ac91d3 / 2017-02-07, built with
>   SMM_REQUIRE, and supporting CPU hotplug. QEMU
>   permits CPU hotplug operations, and causes the
>   OS to inject an SMI upon hotplug. Firmware is
>   expected to deal with hotplug events.
> 
> Negotiate ICH9_LPC_SMI_F_CPU_HOTPLUG -- but only if SEV is disabled, as
> OvmfPkg/CpuHotplugSmm can't deal with SEV yet.
> 
> Cc: Ard Biesheuvel 
> Cc: Boris Ostrovsky 
> Cc: Igor Mammedov 
> Cc: Jordan Justen 
> Cc: Liran Alon 
> Cc: Philippe Mathieu-Daudé 
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> This is the OVMF counterpart to Igor's QEMU series:
> 
> - [RFC 0/3] x86: fix cpu hotplug with secure boot
>   https://lists.gnu.org/archive/html/qemu-devel/2020-07/msg03746.html
>   message-id: <20200710161704.309824-1-imamm...@redhat.com>
> 
> Repo:   https://pagure.io/lersek/edk2.git
> Branch: negotiate_cpuhp_with_smi_rhbz1849177
> 
>  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf |  1 +
>  OvmfPkg/SmmControl2Dxe/SmiFeatures.c  | 26 ++--
>  2 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf 
> b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> index 3abed141e644..b8fdea8deb84 100644
> --- a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> @@ -46,6 +46,7 @@ [LibraryClasses]
>BaseLib
>DebugLib
>IoLib
> +  MemEncryptSevLib
>MemoryAllocationLib
>PcdLib
>PciLib
> diff --git a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c 
> b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> index 6210b7515e3e..c9d875543205 100644
> --- a/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> +++ b/OvmfPkg/SmmControl2Dxe/SmiFeatures.c
> @@ -9,6 +9,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -21,6 +22,12 @@
>  // "etc/smi/supported-features" and "etc/smi/requested-features" fw_cfg 
> files.
>  //
>  #define ICH9_LPC_SMI_F_BROADCAST BIT0
> +//
> +// The following bit value stands for "enable CPU hotplug, and inject an SMI
> +// with control value ICH9_APM_CNT_CPU_HOTPLUG upon hotplug", in the
> +// "etc/smi/supported-features" and "etc/smi/requested-features" fw_cfg 
> files.
> +//
> +#define ICH9_LPC_SMI_F_CPU_HOTPLUG BIT1
>  
>  //
>  // Provides a scratch buffer (allocated in EfiReservedMemoryType type memory)
> @@ -67,6 +74,7 @@ NegotiateSmiFeatures (
>UINTNSupportedFeaturesSize;
>UINTNRequestedFeaturesSize;
>UINTNFeaturesOkSize;
> +  UINT64   RequestedFeaturesMask;
>  
>//
>// Look up the fw_cfg files used for feature negotiation. The selector keys
> @@ -104,9 +112,16 @@ NegotiateSmiFeatures (
>QemuFwCfgReadBytes (sizeof mSmiFeatures, );
>  
>//
> -  // We want broadcast SMI and nothing else.
> +  // We want broadcast SMI, SMI on CPU hotplug, and nothing else.
>//
> -  mSmiFeatures &= ICH9_LPC_SMI_F_BROADCAST;
> +  RequestedFeaturesMask = ICH9_LPC_SMI_F_BROADCAST;
> +  if (!MemEncryptSevIsEnabled ()) {
> +//
> +// For now, we only support hotplug with SEV disabled.
> +//
> +RequestedFeaturesMask |= ICH9_LPC_SMI_F_CPU_HOTPLUG;
> +  }
> +  mSmiFeatures &= RequestedFeaturesMask;
>QemuFwCfgSelectItem (mRequestedFeaturesItem);
>QemuFwCfgWriteBytes (sizeof mSmiFeatures, );
>  
> @@ -144,6 +159,13 @@ NegotiateSmiFeatures (
>  

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

[Laszlo Ersek]

On 08/19/20 20:46, Michael Brown wrote:
> On 19/08/2020 19:13, Laszlo Ersek wrote:
>> I'm still undecided whether option#43 / tag#6 / bit#3 being clear means
>> we should *ignore* PXE_BOOT_SERVERS (tag#8), but I'm willing to defer to
>> you on that. So, I can give a cautious
>>
>> Reviewed-by: Laszlo Ersek 
>>
>> for this patch.
> 
> FWIW, iPXE's equivalent logic (based on a combination of what the PXE
> spec says and what the Intel reference PXE implementation actually does,
> which is not necessarily the same thing) is to *ignore* PXE_BOOT_SERVERS
> if a DHCP filename is available and option 43 tag 6 bit 3 is *set*.

Sorry, I expressed my concern incorrectly (I think I was tripped up by
the typo in Maciej's commit message).

It's about bit#2 in PXE_DISCOVERY_CONTROL.

The question is whether bit#2 is *equivalent* to adhering to
PXE_BOOT_SERVERS ("if, and only if").

When bit#2 is set, the spec says we must. OK.

When bit#2 is clear, the spec doesn't say anything. So two
interpretations are possible, "we still may consider PXE_BOOT_SERVERS",
and "we must not consider PXE_BOOT_SERVERS".

Anyway -- I'm sending this just to explain my earlier email. My main
point remains:

11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com">http://mid.mail-archive.com/11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com

(alt link: https://edk2.groups.io/g/devel/message/64530)

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64535): https://edk2.groups.io/g/devel/message/64535
Mute This Topic: https://groups.io/mt/76290910/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

[Maciej Rabeda]

@Michael
I stand corrected on option 66. I have confused myself with "next 
server" comment in EFI code.


Bugzilla 2876

The more I get into the problem with a fresh mind and a cup of tea, the 
more I realize that it is indeed a problem in reporters configuration.

Reporter stated:
- Failing scenario: tag 6 == 0x7
- Working scenario: tag 6 == 0x3

In the failing scenario, user sets bit 2 (so PXE_BOOT_SERVERS are being 
used) and PXE_BOOT_SERVERS contains ProxyDHCP IP instead of TFTP server.
It should work fine if ProxyDHCP and TFTP sits on the same machine (with 
the same IP).

Case closed, patch to be dropped, BZ to be rejected.

Philosophy / PXE Forced Mode

All I could find about 'PXE Forced Mode' is some non-spec 
tooling/documentation.

https://knowledge.broadcom.com/external/article?legacyId=HOWTO7071
https://knowledge.broadcom.com/external/article/180499/pxe-forced-mode-utility.html

PDF from the first link's page sets up tag 6 to value 11 (bit 3, 1, 0 
are set) and setting up tag 8 with some values.
Now I am sharing the shudder. Why is PXE_BOOT_SERVERS being used when 
tag 6, bit 3 is set?
All I can blame is PXE spec being very vague on the matter or some kind 
of ancient knowledge that I am not aware of.


Thanks,
Maciej.

On 21-Aug-20 11:11, Laszlo Ersek wrote:

On 08/20/20 15:41, Michael Brown wrote:

On 20/08/2020 11:44, Maciej Rabeda wrote:

@Michael
I am now wondering whether bit 3 is actually relevant to server choice.

Bit 3:
== 0 -> prompt user to choose a boot file. Which means to me: show
minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9
- PXE_BOOT_MENU).
== 1 -> do not prompt user. If boot file name is present (option 67),
download that boot file.

Bit 3 does not seem to specify/regulate which server to use.

Choice of server IP might look like:

if (option 43 is present, tag 6 is present, tag_6.bit_2 is set and tag
8 is present and valid)
      take server IP from tag 8 (PXE_BOOT_SERVERS)

else if (option 66 is present)
      take server IP from option 66 (TFTP server name)

else if (option 54 is present)
      take server IP from option 54 (Server Identifier)

else
      failure

RFC 2132 defines option 66 as a hostname (not an IP address): it is the
equivalent of the non-option "sname" field.

RFC 2132 defines option 54 as the DHCP server identifier, which is
unrelated to the TFTP server.

In the simple case (with no PXE menus involved), the TFTP server IP is
provided by the non-option "siaddr" field.

If option 60 is set to "PXEClient" and option 43 tag 9 is present and
option 43 tag 6 bit 3 is clear then this initiates a convoluted process
in which the user is first presented with an interactive menu
(constructed from the contents of option 43 tag 9) in order to select a
"boot server type", after which a second convoluted process is performed
to query the network using a protocol that is almost, but not quite,
entirely unlike DHCP.  The TFTP server IP and boot filename are
eventually taken from the selected response packet in this final
almost-DHCP exchange.

*shudder*

I'll 100% defer to you and Maciej on this -- this is very complicated.

To begin with, I'm not fully clear what the purpose of edk2 git commit
ecec42044078 ("Update PXE driver to support PXE forced mode.",
2014-01-06) was.

What on Earth is "PXE forced mode"?

Siyuan, can you please explain?

And then I don't know whether the bug report at

   https://bugzilla.tianocore.org/show_bug.cgi?id=2876

really has merit.

In the words of the reporter, the presently discussed patch would still
qualify as a "work-around", for making the PXE client ignore
PXE_BOOT_SERVERS, via clearing option#43 tag#6 bit#2 in the DHCP server
response. But IMO the more important question is whether it is valid for
the DHCP server (config) at their site to (a) populate PXE_BOOT_SERVERS,
(b) put (apparently!) the ProxyDHCP IP address in PXE_BOOT_SERVERS.

Like, I'd like to be convinced that the server config at the reporter's
site is not *invalid* in the first place. If it's invalid, then we
shouldn't be complicating the edk2 client code with a workaround. Even
if we adopted the workaround, the reporter would still have to
*activate* it, by manually clearing the bit in question (see at the very
end of ).

For me one big difficulty is that the PXE config options are scattered
about a forest of specs. Last time I spent more than an hour cursing and
hunting for them.

At Red Hat, over the last few years I've received an immense amount of
bug reports related to PXEv4/PXEv6 booting with edk2. In almost every
case, it was a bug in the reporter's server configuration. Yes,
anecdotal evidence. It makes me very reluctant to change the edk2 code,
especially that the reporter of TianoCore#2876 has seemingly stopped
communications.

Note how the bug report makes references to various attachments, such as
RAR files and one 

Re: [edk2-devel] Patch List for 202008 stable tag

[Laszlo Ersek]

On 08/20/20 17:41, Vladimir Olovyannikov wrote:

> I am sending the revised patch set today. The patchset adds "http"
> command which works the same way as tftp. I am not sure how important
> it is, as this is an improvement, not a bug fix. When these are in,
> OvmfPkg/ArmVirtPkg will have this feature in as well. @Laszlo Laszlo,
> can you please add your comment?

Expanding on what I said elsewhere in this thread, I'd like to confirm
that, *whenever* the HTTP dynamic command is merged, the dependent
OvmfPkg/ArmVirtPkg patches can / should be merged too, as they have been
reviewed and test earlier, in the thread linked in the bugzilla comment at

  https://bugzilla.tianocore.org/show_bug.cgi?id=2857#c2

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64533): https://edk2.groups.io/g/devel/message/64533
Mute This Topic: https://groups.io/mt/76306021/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Patch List for 202008 stable tag

[Laszlo Ersek]

On 08/20/20 13:30, Gao, Liming wrote:
> Hi Stewards and all:
>   I collect current patch lists in devel mail list. Those patch contributors 
> request to add them for 202008 stable tag. Because we have enter into Soft 
> Feature Freeze, I want to collect your feedback for them. If any patches are 
> missing, please reply this mail to add them.
> 
> Feature List:
> https://edk2.groups.io/g/devel/message/63767 [PATCH] EmbeddedPkg/libfdt: Add 
> strncmp macro to use AsciiStrnCmp
> [Liming] This patch pass code review after Soft Feature Freeze (SFF) starts. 
> According to SFF definition, it should not be merged for this stable tag. 
> But, the patch submitter says this patch is important to RISC-V community. To 
> catch it for this stable tag, Laszlo proposed the solution to defer SFF start 
> day from 2020-08-14 to 2020-08-21, then hard feature freeze and release date 
> will also defer one week. Any patches those pass review before new SFF start 
> day can be merged. @ Stewards, please give your comments to defer this stable 
> tag release by one week.

Thank you, very nice summary.

As stated earlier, I'm OK with 1 week (or even two weeks, if needed)
extension. I invite Andrew, Leif and Mike to comment.

> 
> https://edk2.groups.io/g/devel/message/63348 [PATCH v5 1/1] 
> ShellPkg/DynamicCommand: add HttpDynamicCommand
> [Liming] This patch has collected the review comment. New version will be 
> sent. I have no information how important it is. @Vladimir, does this patch 
> must catch this stable tag? If yes, can you give the reason?

This is a feature addition. While it's a super useful feature, it needs
to mature (mainly from the coding style perspective, as I gather).
Posting of new versions and review are on-going.

Most likely material for the next stable tag. In case we extend the
deadlines, and Maciej and the ShellPkg maintainers approve one of the
upcoming versions until the new SFF, then yes, we can merge that too.

> Bug List:
> https://edk2.groups.io/g/devel/message/64383 [PATCH 1/1] 
> UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable
> [Liming] This patch has collected the review comment. New version will be 
> sent.

This is a bugfix. Certainly a build fix on CLANGPDB. I tried to do some
(lightweight) analysis to see whether the bug is a functional one as
well (i.e. whether the bad code path that CLANG warns about can actually
occur in practice), but in the end I didn't want to spend much time on
it, as the build breakage needs to be fixed anyway.

So, this patch (more precisely, v2 of this patch) would even qualify
during the hard feature freeze (as it's clearly a bugfix).

> 
> https://edk2.groups.io/g/devel/message/50406 [PATCH 1/1] MdePkg/Include: Add 
> missing definitions of SMBIOS type 42h in SmBios.h
> [Liming] This patch passed review early. But, it is not merged. I will merge 
> it.

Right, it was approved on 2019-Nov-18. If it still applies cleanly, it
should be merged, before we enter the Hard Feature Freeze.

Well... now that I'm writing this, we have already entered the HFF (as
planned originally) and the patch doesn't seem to be upstream yet. So
unless we extend, I don't think this patch qualifies.

(On the other hand -- it seems like we really should extend.)

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64532): https://edk2.groups.io/g/devel/message/64532
Mute This Topic: https://groups.io/mt/76306021/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] UefiCpuPkg/MpInitLib: Always initialize the DoDecrement variable

[Laszlo Ersek]

On 08/20/20 16:53, Tom Lendacky wrote:
> From: Tom Lendacky 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2901
> 
> The DoDecrement variable in ApWakeupFunction () wasn't always being
> initialized. Update the code to always fully initialize it.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 90416c81b616..07426274f639 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -885,9 +885,7 @@ ApWakeupFunction (
>UINT64Status;
>BOOLEAN   DoDecrement;
>  
> -  if (CpuMpData->InitFlag == ApInitConfig) {
> -DoDecrement = TRUE;
> -  }
> +  DoDecrement = (BOOLEAN) (CpuMpData->InitFlag == ApInitConfig);
>  
>while (TRUE) {
>  Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
> 

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64531): https://edk2.groups.io/g/devel/message/64531
Mute This Topic: https://groups.io/mt/76309738/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow

[Laszlo Ersek]

On 08/20/20 15:41, Michael Brown wrote:
> On 20/08/2020 11:44, Maciej Rabeda wrote:
>> @Michael
>> I am now wondering whether bit 3 is actually relevant to server choice.
>>
>> Bit 3:
>> == 0 -> prompt user to choose a boot file. Which means to me: show
>> minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9
>> - PXE_BOOT_MENU).
>> == 1 -> do not prompt user. If boot file name is present (option 67),
>> download that boot file.
>>
>> Bit 3 does not seem to specify/regulate which server to use.
>>
>> Choice of server IP might look like:
>>
>> if (option 43 is present, tag 6 is present, tag_6.bit_2 is set and tag
>> 8 is present and valid)
>>      take server IP from tag 8 (PXE_BOOT_SERVERS)
>>
>> else if (option 66 is present)
>>      take server IP from option 66 (TFTP server name)
>>
>> else if (option 54 is present)
>>      take server IP from option 54 (Server Identifier)
>>
>> else
>>      failure
> 
> RFC 2132 defines option 66 as a hostname (not an IP address): it is the
> equivalent of the non-option "sname" field.
> 
> RFC 2132 defines option 54 as the DHCP server identifier, which is
> unrelated to the TFTP server.
> 
> In the simple case (with no PXE menus involved), the TFTP server IP is
> provided by the non-option "siaddr" field.
> 
> If option 60 is set to "PXEClient" and option 43 tag 9 is present and
> option 43 tag 6 bit 3 is clear then this initiates a convoluted process
> in which the user is first presented with an interactive menu
> (constructed from the contents of option 43 tag 9) in order to select a
> "boot server type", after which a second convoluted process is performed
> to query the network using a protocol that is almost, but not quite,
> entirely unlike DHCP.  The TFTP server IP and boot filename are
> eventually taken from the selected response packet in this final
> almost-DHCP exchange.

*shudder*

I'll 100% defer to you and Maciej on this -- this is very complicated.

To begin with, I'm not fully clear what the purpose of edk2 git commit
ecec42044078 ("Update PXE driver to support PXE forced mode.",
2014-01-06) was.

What on Earth is "PXE forced mode"?

Siyuan, can you please explain?

And then I don't know whether the bug report at

  https://bugzilla.tianocore.org/show_bug.cgi?id=2876

really has merit.

In the words of the reporter, the presently discussed patch would still
qualify as a "work-around", for making the PXE client ignore
PXE_BOOT_SERVERS, via clearing option#43 tag#6 bit#2 in the DHCP server
response. But IMO the more important question is whether it is valid for
the DHCP server (config) at their site to (a) populate PXE_BOOT_SERVERS,
(b) put (apparently!) the ProxyDHCP IP address in PXE_BOOT_SERVERS.

Like, I'd like to be convinced that the server config at the reporter's
site is not *invalid* in the first place. If it's invalid, then we
shouldn't be complicating the edk2 client code with a workaround. Even
if we adopted the workaround, the reporter would still have to
*activate* it, by manually clearing the bit in question (see at the very
end of ).

For me one big difficulty is that the PXE config options are scattered
about a forest of specs. Last time I spent more than an hour cursing and
hunting for them.

At Red Hat, over the last few years I've received an immense amount of
bug reports related to PXEv4/PXEv6 booting with edk2. In almost every
case, it was a bug in the reporter's server configuration. Yes,
anecdotal evidence. It makes me very reluctant to change the edk2 code,
especially that the reporter of TianoCore#2876 has seemingly stopped
communications.

Note how the bug report makes references to various attachments, such as
RAR files and one "Serva32.exe", regarding a reproducer. But until now,
with the latest comment being #9, those files have *not* been attached.
So it's not like we can set up some virtual machines on a virtual
network and fire up wireshark or tcpdump, to see the actual traffic.

I'm happy to pull out of this review session, as I trust you Michael and
Maciej to do the right here. I'm happy to offer some level of regression
testing, if you got new patches. I'd also be OK to simply close
TianoCore#2876 as INVALID (due to insufficient data).

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64530): https://edk2.groups.io/g/devel/message/64530
Mute This Topic: https://groups.io/mt/76290910/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] .pytool/EccCheck: Disable Ecc error code 10014 for open CI

[Zhang, Shenglei]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2920
Ecc issues whose error code is 10014, can't be correctly handled
under Linux OS, resulting from a bug in Ecc tool.
So we need to disable it before ecc tool is repaired.

Cc: Sean Brogan 
Cc: Bret Barkelew 
Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Shenglei Zhang 
---
 .pytool/Plugin/EccCheck/EccCheck.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.pytool/Plugin/EccCheck/EccCheck.py 
b/.pytool/Plugin/EccCheck/EccCheck.py
index eee1ff7a77b5..3eaad0bf5623 100644
--- a/.pytool/Plugin/EccCheck/EccCheck.py
+++ b/.pytool/Plugin/EccCheck/EccCheck.py
@@ -301,6 +301,7 @@ class EccCheck(ICiBuildPlugin):
  "10011",
  "10012",
  "10013",
+ "10014", #need to be removed after BZ2904 is fixed
  "10015",
  "10016",
  "10017",
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64529): https://edk2.groups.io/g/devel/message/64529
Mute This Topic: https://groups.io/mt/76325475/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] running CI locally

[Laszlo Ersek]

Hi Mike, Sean;

On 08/19/20 19:59, Laszlo Ersek wrote:

> I'll report back with more results.

I installed a Fedora 32 Server VM.

Installed the "mono-complete" package (+its deps).

Installed the "nodejs" package.

Installed "cspell" (+deps) with "npm" (with the latter coming from the
nodejs package).

Edk2 checked out at current HEAD
(5a6d764e1d073d28e8f398289ccb5592bf9a72ba).


* Platform CI results:

- :

  Built successfully for IA32, X64, and IA32X64 (toolchain: GCC5).

- :

  Built successfully for ARM and AARCH64 (toolchain: GCC5).


* Core CI results:

- 

  Complete run successful (toolchain: GCC5); no package / arch / target
  / test restrictions.

  I got the following WARNINGs:

  - ArmVirtPkg, EmulatorPkg, and OvmfPkg are covered by Platform CI, not
Core CI -- these are expected:

> PROGRESS - --Running ArmVirtPkg: Compiler Plugin DEBUG --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
> PROGRESS - --Running ArmVirtPkg: Compiler Plugin RELEASE --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE

> PROGRESS - --Running EmulatorPkg: Compiler Plugin DEBUG --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
> PROGRESS - --Running EmulatorPkg: Compiler Plugin RELEASE --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE

> PROGRESS - --Running OvmfPkg: Compiler Plugin DEBUG --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin DEBUG
> PROGRESS - --Running OvmfPkg: Compiler Plugin RELEASE --
> WARNING - --->Test Skipped: in plugin! Compiler Plugin RELEASE

  - ArmVirtPkg, DynamicTablesPkg, CryptoPkg, EmulatorPkg, FatPkg,
NetworkPkg, OvmfPkg, PcAtChipsetPkg, SecurityPkg and ShellPkg are
not covered by host-based unit tests -- I think also expected:

> PROGRESS - --Running ArmVirtPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running DynamicTablesPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running CryptoPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running EmulatorPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running FatPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running NetworkPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running OvmfPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running PcAtChipsetPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running SecurityPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

> PROGRESS - --Running ShellPkg: Host Unit Test Compiler Plugin NOOPT --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Compiler Plugin NOOPT

  - I'm not really sure about the following warnings. They were emitted
for a subset of the above packages. I read the docs at


but I still don't understand :)

> PROGRESS - --Running CryptoPkg: Host Unit Test Dsc Complete Check Test 
> NO-TARGET --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

> PROGRESS - --Running FatPkg: Host Unit Test Dsc Complete Check Test NO-TARGET 
> --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

> PROGRESS - --Running NetworkPkg: Host Unit Test Dsc Complete Check Test 
> NO-TARGET --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

> PROGRESS - --Running PcAtChipsetPkg: Host Unit Test Dsc Complete Check Test 
> NO-TARGET --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

> PROGRESS - --Running SecurityPkg: Host Unit Test Dsc Complete Check Test 
> NO-TARGET --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

> PROGRESS - --Running ShellPkg: Host Unit Test Dsc Complete Check Test 
> NO-TARGET --
> WARNING - --->Test Skipped: in plugin! Host Unit Test Dsc Complete Check Test 
> NO-TARGET

  - Still related to host-based unit tests, I believe the following
warnings, for 

[edk2-devel] [PATCH] MdePkg: Remove code wrapped by DISABLE_NEW_DEPRECATED_INTERFACES

[Ming Huang via groups.io]

Hi, Leif

For Hisilicon platform, Wenyi(xiewen...@huawei.com) will send out patches later.

Thanks
Ming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64527): https://edk2.groups.io/g/devel/message/64527
Mute This Topic: https://groups.io/mt/74688627/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary measurement

[Bret Barkelew via groups.io]

Awesome. That gives me a little time. Thanks, Jiewen! And thanks for tracking 
the issue.

- Bret

From: Yao, Jiewen
Sent: Thursday, August 20, 2020 11:16 PM
To: devel@edk2.groups.io; Bret 
Barkelew; Zhang, 
Qi1
Cc: Wang, Jian J; Wu, Hao 
A; Chiu, Chasel; 
Desimone, Nathaniel L; Zeng, 
Star
Subject: RE: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary 
measurement

We are in SFF.
I posted to 
https://github.com/jyao1/edk2/tree/FspManifestNew
 temporarily.

Please let us know if you have any feedback.
I plan to post after the 202008 stable tag.

Thank you
Yao Jiewen


From: devel@edk2.groups.io  On Behalf Of Bret Barkelew 
via groups.io
Sent: Friday, August 21, 2020 1:56 PM
To: devel@edk2.groups.io; Zhang, Qi1 
Cc: Yao, Jiewen ; Wang, Jian J ; 
Wu, Hao A ; Chiu, Chasel ; Desimone, 
Nathaniel L ; Zeng, Star 
Subject: Re: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary 
measurement

Does this live in a branch somewhere? I'd like to take a look at it and make 
sure it fully replaces our current custom solution.

Thanks!


- Bret


From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Qi Zhang via 
groups.io mailto:qi1.zhang=intel@groups.io>>
Sent: Monday, August 17, 2020 11:26 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Qi Zhang mailto:qi1.zh...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>; Jian J Wang 
mailto:jian.j.w...@intel.com>>; Hao A Wu 
mailto:hao.a...@intel.com>>; Chasel Chiu 
mailto:chasel.c...@intel.com>>; Desimone, Nathaniel L 
mailto:nathaniel.l.desim...@intel.com>>; Star 
Zeng mailto:star.z...@intel.com>>
Subject: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary 
measurement

v4 change:
   rename FvEventLogRecordLib to TcgEventLogRecordLib.
v3 change:
  add a new lib FvEventLogRecordLib for gerneric code.

REF: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2376data=02%7C01%7CBret.Barkelew%40microsoft.com%7C0a458f4d4eea4c503fe908d8433fa25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333287874367194sdata=SGpI04kc3Tcoo36CQ903bnTN2NFPUxoc8YzIwzIdfcs%3Dreserved=0

The EDKII BIOS calls FSP API in FSP Wrapper Pkg.
This FSP code need to be measured into TPM.

We need add a generic module in FSP Wrapper Pkg code to measure:
1) FSP-T, FSP-M, FSP-S in API mode.
2) FSP-T in Dispatch-mode. The FSP-M and FSP-S will be reported
   as standard FV and they will be measured by TCG-PEI.

Cc: Jiewen Yao mailto:jiewen@intel.com>>
Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Chasel Chiu mailto:chasel.c...@intel.com>>
Cc: Nate DeSimone 
mailto:nathaniel.l.desim...@intel.com>>
Cc: Star Zeng mailto:star.z...@intel.com>>
Cc: Qi Zhang mailto:qi1.zh...@intel.com>>

Jiewen Yao (4):
  IntelFsp2WrapperPkg/FspMeasurementLib: Add header file.
  IntelFsp2WrapperPkg/FspMeasurementLib: Add BaseFspMeasurementLib.
  IntelFsp2WraperPkg/Fsp{m|s}WrapperPeim: Add FspBin measurement.
  IntelFsp2Wrapper/dsc: Add FspTpmMeasurementLib and
PcdFspMeasurementConfig.

Qi Zhang (4):
  SecurityPkg/TcgEventLogRecordLib: add new lib for firmware measurement
  SecurityPkg/dsc: add FvEventLogRecordLib
  SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY
  IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and Tpm2DeviceLib

 .../FspmWrapperPeim/FspmWrapperPeim.c |  90 ++-
 .../FspmWrapperPeim/FspmWrapperPeim.inf   |  20 +-
 .../FspsWrapperPeim/FspsWrapperPeim.c |  86 +-
 .../FspsWrapperPeim/FspsWrapperPeim.inf   |  27 +-
 .../Include/Library/FspMeasurementLib.h   |  39 +++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec   |  17 ++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc   |  10 +-
 .../BaseFspMeasurementLib.inf |  54 
 .../BaseFspMeasurementLib/FspMeasurementLib.c | 248 ++
 .../Include/Library/TcgEventLogRecordLib.h|  97 +++
 SecurityPkg/Include/Ppi/Tcg.h |   5 +
 .../TcgEventLogRecordLib.c| 197 

Re: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary measurement

[Yao, Jiewen]

We are in SFF.
I posted to https://github.com/jyao1/edk2/tree/FspManifestNew temporarily.

Please let us know if you have any feedback.
I plan to post after the 202008 stable tag.

Thank you
Yao Jiewen


From: devel@edk2.groups.io  On Behalf Of Bret Barkelew 
via groups.io
Sent: Friday, August 21, 2020 1:56 PM
To: devel@edk2.groups.io; Zhang, Qi1 
Cc: Yao, Jiewen ; Wang, Jian J ; 
Wu, Hao A ; Chiu, Chasel ; Desimone, 
Nathaniel L ; Zeng, Star 
Subject: Re: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary 
measurement

Does this live in a branch somewhere? I'd like to take a look at it and make 
sure it fully replaces our current custom solution.

Thanks!


- Bret


From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> on behalf of Qi Zhang via 
groups.io mailto:qi1.zhang=intel@groups.io>>
Sent: Monday, August 17, 2020 11:26 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>
Cc: Qi Zhang mailto:qi1.zh...@intel.com>>; Yao, Jiewen 
mailto:jiewen@intel.com>>; Jian J Wang 
mailto:jian.j.w...@intel.com>>; Hao A Wu 
mailto:hao.a...@intel.com>>; Chasel Chiu 
mailto:chasel.c...@intel.com>>; Desimone, Nathaniel L 
mailto:nathaniel.l.desim...@intel.com>>; Star 
Zeng mailto:star.z...@intel.com>>
Subject: [EXTERNAL] [edk2-devel] [PATCH v4 0/8] Need add a FSP binary 
measurement

v4 change:
   rename FvEventLogRecordLib to TcgEventLogRecordLib.
v3 change:
  add a new lib FvEventLogRecordLib for gerneric code.

REF: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2376data=02%7C01%7CBret.Barkelew%40microsoft.com%7C0a458f4d4eea4c503fe908d8433fa25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333287874367194sdata=SGpI04kc3Tcoo36CQ903bnTN2NFPUxoc8YzIwzIdfcs%3Dreserved=0

The EDKII BIOS calls FSP API in FSP Wrapper Pkg.
This FSP code need to be measured into TPM.

We need add a generic module in FSP Wrapper Pkg code to measure:
1) FSP-T, FSP-M, FSP-S in API mode.
2) FSP-T in Dispatch-mode. The FSP-M and FSP-S will be reported
   as standard FV and they will be measured by TCG-PEI.

Cc: Jiewen Yao mailto:jiewen@intel.com>>
Cc: Jian J Wang mailto:jian.j.w...@intel.com>>
Cc: Hao A Wu mailto:hao.a...@intel.com>>
Cc: Chasel Chiu mailto:chasel.c...@intel.com>>
Cc: Nate DeSimone 
mailto:nathaniel.l.desim...@intel.com>>
Cc: Star Zeng mailto:star.z...@intel.com>>
Cc: Qi Zhang mailto:qi1.zh...@intel.com>>

Jiewen Yao (4):
  IntelFsp2WrapperPkg/FspMeasurementLib: Add header file.
  IntelFsp2WrapperPkg/FspMeasurementLib: Add BaseFspMeasurementLib.
  IntelFsp2WraperPkg/Fsp{m|s}WrapperPeim: Add FspBin measurement.
  IntelFsp2Wrapper/dsc: Add FspTpmMeasurementLib and
PcdFspMeasurementConfig.

Qi Zhang (4):
  SecurityPkg/TcgEventLogRecordLib: add new lib for firmware measurement
  SecurityPkg/dsc: add FvEventLogRecordLib
  SecurityPkg/Tcg2: handle PRE HASH and LOG ONLY
  IntelFsp2WrapperPkg/dsc: add HashLib, Tpm2CommandLib and Tpm2DeviceLib

 .../FspmWrapperPeim/FspmWrapperPeim.c |  90 ++-
 .../FspmWrapperPeim/FspmWrapperPeim.inf   |  20 +-
 .../FspsWrapperPeim/FspsWrapperPeim.c |  86 +-
 .../FspsWrapperPeim/FspsWrapperPeim.inf   |  27 +-
 .../Include/Library/FspMeasurementLib.h   |  39 +++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dec   |  17 ++
 IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc   |  10 +-
 .../BaseFspMeasurementLib.inf |  54 
 .../BaseFspMeasurementLib/FspMeasurementLib.c | 248 ++
 .../Include/Library/TcgEventLogRecordLib.h|  97 +++
 SecurityPkg/Include/Ppi/Tcg.h |   5 +
 .../TcgEventLogRecordLib.c| 197 ++
 .../TcgEventLogRecordLib.inf  |  40 +++
 .../TcgEventLogRecordLib.uni  |  17 ++
 SecurityPkg/SecurityPkg.dec   |   3 +
 SecurityPkg/SecurityPkg.dsc   |   2 +
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c |  12 +-
 17 files changed, 939 insertions(+), 25 deletions(-)
 create mode 100644 IntelFsp2WrapperPkg/Include/Library/FspMeasurementLib.h
 create mode 100644 
IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/BaseFspMeasurementLib.inf
 create mode 100644 
IntelFsp2WrapperPkg/Library/BaseFspMeasurementLib/FspMeasurementLib.c
 create mode 100644 SecurityPkg/Include/Library/TcgEventLogRecordLib.h
 create mode 100644 
SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.c
 create mode 100644 
SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.inf
 create mode 100644 
SecurityPkg/Library/TcgEventLogRecordLib/TcgEventLogRecordLib.uni

--
2.26.2.windows.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#64525): https://edk2.groups.io/g/devel/message/64525
Mute This Topic: https://groups.io/mt/76324169/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: