[edk2-devel] 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

2019-05-19 Thread Jerry Zhou(BJ-RD)
OK.
I have submitted to Bugzilla.
Bug 1823 - source code about disabling the DMAR of IOMMU in IntelSiliconPkg

Thank you
Jerry Zhou
发件人: Yao, Jiewen [mailto:jiewen@intel.com]
发送时间: 2019年5月20日 14:09
收件人: Zeng, Star; Jerry Zhou(BJ-RD); edk2-de...@lists.01.org; 
devel@edk2.groups.io
抄送: Ni, Ray; Yao, Jiewen
主题: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

Thanks.
We are also reviewing the VTd disabling flow and may update recently.

If you want to file Bugzilla, please go ahead.

Thank you
Yao Jiewen

From: Zeng, Star
Sent: Sunday, May 19, 2019 8:33 PM
To: Jerry Zhou(BJ-RD) ; edk2-de...@lists.01.org; 
devel@edk2.groups.io
Cc: Yao, Jiewen ; Ni, Ray ; Zeng, Star 

Subject: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code

Actually, I agree with you.
Personally, I think more rigorous flow could be like below.

1.  Clear B_GMCD_REG_TE, wait B_GSTS_REG_TE to be cleared.

2.  Set B_GMCD_REG_SRTP, wait B_GSTS_REG_RTPS to be set.

3.  Zero R_RTADDR_REG.

Not sure original code developer Jiewen’s thought about this.


You may submit Bugzilla at https://bugzilla.tianocore.org if you wait.


Thanks,
Star

From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 7:28 PM
To: Zeng, Star mailto:star.z...@intel.com>>; 
edk2-de...@lists.01.org; 
devel@edk2.groups.io
Cc: Yao, Jiewen mailto:jiewen@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code

Got it! Thanks for your reply.
But you should still poll the B_GSTS_REG_TE bit, not the B_GSTS_REG_RTPS bit, 
in the judgement code of while() loop.
After & operation between Reg32 and B_GSTS_REG_RTPS, the status of 
B_GSTS_REG_TE will be lost.

A more tedious but more reliable operation sequence is recommended in Vt-d 
specification 2.4 below:

to update a bit field in this register at offset X with value of Y, software
must follow below steps:
1. Tmp = Read GSTS_REG
2. Status = (Tmp & 96FFh) // Reset the one-shot bits
3. Command = (Status | (Y << X))
4. Write Command to GCMD_REG
5. Wait until GSTS_REG[X] indicates command is serviced.
发件人: Zeng, Star [mailto:star.z...@intel.com]
发送时间: 2019年5月13日 18:54
收件人: Jerry Zhou(BJ-RD); edk2-de...@lists.01.org
抄送: Yao, Jiewen; Ni, Ray; Zeng, Star
主题: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

Good question, my understanding is setting B_GMCD_REG_SRTP(BIT30) ONLY also 
means clearing B_GMCD_REG_TE (BIT31).

Thanks,
Star
From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 10:59 AM
To: Zeng, Star mailto:star.z...@intel.com>>; 
edk2-de...@lists.01.org
Cc: Yao, Jiewen mailto:jiewen@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code


Hi Star,

 I'am so interested in DMA protection in UEFI. It's a really good 
design!

 But I have a question about the implemention of DisableDmar() in 
IntelSiliconPkg\feature\vtd\intelvtddxe\VtdReg.c

 Is it a typing error in the code segment below?



//

// Disable VTd

//

MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);

do {

  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);

} while((Reg32 & B_GSTS_REG_RTPS) == 0);



The software should program the B_GMCD_REG_TE field in global command register 
and then poll the B_GSTS_REG_TE field in global status register if the DMAR is 
expected to be disabled or enabled according to Vt-d specification.



Thanks

Jerry Zhou

Ext:892418







-邮件原件-
发件人: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] 代表 Star Zeng
发送时间: 2018年10月24日 11:32
收件人: edk2-de...@lists.01.org
抄送: Jiewen Yao; Star Zeng
主题: [edk2] [PATCH] IntelSiliconPkg VTdDxe: Option to force no early access attr 
request



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



To have high confidence in usage for platform, add option (BIT2 of

PcdVTdPolicyPropertyMask) to force no IOMMU access attribute request

recording before DMAR table is installed.



Check PcdVTdPolicyPropertyMask BIT2 before RequestAccessAttribute()

and ProcessRequestedAccessAttribute(), then RequestAccessAttribute(),

ProcessRequestedAccessAttribute() and mAccessRequestXXX variables

could be optimized by compiler when PcdVTdPolicyPropertyMask BIT2 = 1.



Test done:

1: Created case that has IOMMU access attribute request before DMAR

   table is installed, ASSERT was triggered after setting

   PcdVTdPolicyPropertyMask BIT2 to 1.



2. Confirmed RequestAccessAttribute(), ProcessRequestedAccessAttribute()

   and mAccessRequestXXX variables were optimized by compiler after

   setting PcdVTdPolicyPropertyMa

Re: [edk2-devel] [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

2019-05-19 Thread Yao, Jiewen
Thanks.
We are also reviewing the VTd disabling flow and may update recently.

If you want to file Bugzilla, please go ahead.

Thank you
Yao Jiewen

From: Zeng, Star
Sent: Sunday, May 19, 2019 8:33 PM
To: Jerry Zhou(BJ-RD) ; edk2-de...@lists.01.org; 
devel@edk2.groups.io
Cc: Yao, Jiewen ; Ni, Ray ; Zeng, Star 

Subject: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code

Actually, I agree with you.
Personally, I think more rigorous flow could be like below.

1.  Clear B_GMCD_REG_TE, wait B_GSTS_REG_TE to be cleared.

2.  Set B_GMCD_REG_SRTP, wait B_GSTS_REG_RTPS to be set.

3.  Zero R_RTADDR_REG.

Not sure original code developer Jiewen’s thought about this.


You may submit Bugzilla at https://bugzilla.tianocore.org if you wait.


Thanks,
Star

From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 7:28 PM
To: Zeng, Star mailto:star.z...@intel.com>>; 
edk2-de...@lists.01.org; 
devel@edk2.groups.io
Cc: Yao, Jiewen mailto:jiewen@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code

Got it! Thanks for your reply.
But you should still poll the B_GSTS_REG_TE bit, not the B_GSTS_REG_RTPS bit, 
in the judgement code of while() loop.
After & operation between Reg32 and B_GSTS_REG_RTPS, the status of 
B_GSTS_REG_TE will be lost.

A more tedious but more reliable operation sequence is recommended in Vt-d 
specification 2.4 below:

to update a bit field in this register at offset X with value of Y, software
must follow below steps:
1. Tmp = Read GSTS_REG
2. Status = (Tmp & 96FFh) // Reset the one-shot bits
3. Command = (Status | (Y << X))
4. Write Command to GCMD_REG
5. Wait until GSTS_REG[X] indicates command is serviced.
发件人: Zeng, Star [mailto:star.z...@intel.com]
发送时间: 2019年5月13日 18:54
收件人: Jerry Zhou(BJ-RD); edk2-de...@lists.01.org
抄送: Yao, Jiewen; Ni, Ray; Zeng, Star
主题: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

Good question, my understanding is setting B_GMCD_REG_SRTP(BIT30) ONLY also 
means clearing B_GMCD_REG_TE (BIT31).

Thanks,
Star
From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 10:59 AM
To: Zeng, Star mailto:star.z...@intel.com>>; 
edk2-de...@lists.01.org
Cc: Yao, Jiewen mailto:jiewen@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code


Hi Star,

 I'am so interested in DMA protection in UEFI. It's a really good 
design!

 But I have a question about the implemention of DisableDmar() in 
IntelSiliconPkg\feature\vtd\intelvtddxe\VtdReg.c

 Is it a typing error in the code segment below?



//

// Disable VTd

//

MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);

do {

  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);

} while((Reg32 & B_GSTS_REG_RTPS) == 0);



The software should program the B_GMCD_REG_TE field in global command register 
and then poll the B_GSTS_REG_TE field in global status register if the DMAR is 
expected to be disabled or enabled according to Vt-d specification.



Thanks

Jerry Zhou

Ext:892418







-邮件原件-
发件人: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] 代表 Star Zeng
发送时间: 2018年10月24日 11:32
收件人: edk2-de...@lists.01.org
抄送: Jiewen Yao; Star Zeng
主题: [edk2] [PATCH] IntelSiliconPkg VTdDxe: Option to force no early access attr 
request



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



To have high confidence in usage for platform, add option (BIT2 of

PcdVTdPolicyPropertyMask) to force no IOMMU access attribute request

recording before DMAR table is installed.



Check PcdVTdPolicyPropertyMask BIT2 before RequestAccessAttribute()

and ProcessRequestedAccessAttribute(), then RequestAccessAttribute(),

ProcessRequestedAccessAttribute() and mAccessRequestXXX variables

could be optimized by compiler when PcdVTdPolicyPropertyMask BIT2 = 1.



Test done:

1: Created case that has IOMMU access attribute request before DMAR

   table is installed, ASSERT was triggered after setting

   PcdVTdPolicyPropertyMask BIT2 to 1.



2. Confirmed RequestAccessAttribute(), ProcessRequestedAccessAttribute()

   and mAccessRequestXXX variables were optimized by compiler after

   setting PcdVTdPolicyPropertyMask BIT2 to 1.



Cc: Jiewen Yao mailto:jiewen@intel.com>>

Cc: Rangasai V Chaganty 
mailto:rangasai.v.chaga...@intel.com>>

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Star Zeng mailto:star.z...@intel.com>>

---

IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c | 8 +++-

IntelSiliconPkg/Feature/VTd/IntelVTdDxe/IntelVTdDxe.c   | 7 +++

IntelSi

Re: [edk2-devel] Reviewer for the possible duplicated CSM components in OvmfPkg

2019-05-19 Thread Wu, Hao A
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Monday, May 20, 2019 1:40 PM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Laszlo Ersek; Ni, Ray; Justen, Jordan L; Ard Biesheuvel
> Subject: Re: Reviewer for the possible duplicated CSM components in OvmfPkg
> 
> On Mon, 2019-05-20 at 05:32 +, Wu, Hao A wrote:
> > My thought on this is the CSM components in the framework packages are
> > stable for a period of time. So my guess is that the issue is not directly
> > related to these components.
> 
> Right. I went back to a SeaBIOS and OVMF from the time I last had this
> working, and then I tripped over lots of toolchain issues. I ended up
> having to git-bisect for various different issues at once.
> 
> ISTR I eventually got to the point where I could build the "last known
> good" versions with the minimal set of fixes... and still they didn't
> actually work. I need to revisit that.
> 
> > Also, if it turns out that there are some missing components left
> > uncopied, we are able to get them back (from the repo history) and put
> > them into OvmfPkg then. I can help on that.
> >
> > Does this sound good to you?
> 
> That would be great. Thanks. I don't think there's anything really
> *missing*. We do get into SeaBIOS as a CSM but SeaBIOS itself then
> crashes somehow, in a hard-to-debug way.
> 
> In fact I did all this before we had proper SMM support in OVMF and
> SeaBIOS, and I should probably revisit it completely. Originally I took
> the simple approach where SeaBIOS takes over the hardware completely,
> and returning from CSM to UEFI on a boot failure was not really going
> to work. But if I move to what I understand is the "normal" CSM model
> of invoking UEFI services through SMM instead of taking full control,
> things might be a little saner.

Got it. Thanks for the clarification.

I will update my proposed series by adding a leading patch to update the
Maintainers.txt file with:

OvmfPkg
...
R: David Woodhouse 
   (CSM modules)

Also, I will probably held the v2 of the series after the
edk2-stable201905, will let you know if there is any additional help needed.

Thanks again for the help.

Best Regards,
Hao Wu


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

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



Re: [edk2-devel] Reviewer for the possible duplicated CSM components in OvmfPkg

2019-05-19 Thread Wu, Hao A
> -Original Message-
> From: David Woodhouse [mailto:dw...@infradead.org]
> Sent: Monday, May 20, 2019 1:11 PM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Laszlo Ersek; Ni, Ray; Justen, Jordan L; Ard Biesheuvel
> Subject: Re: Reviewer for the possible duplicated CSM components in OvmfPkg
> 
> On Mon, 2019-05-20 at 05:08 +, Wu, Hao A wrote:
> > Hello David,
> >
> > According to the request in a previous mail discussion thread
> > 'Drop CSM support in OvmfPkg?':
> >
> > https://edk2.groups.io/g/devel/topic/30916686#35723
> >
> > We plan to duplicate the required CSM modules into the OvmfPkg/Csm folder,
> > so that those modules will be kept within the edk2 repo.
> >
> > Meanwhile, Laszlo suggested me to first figure out the ownership (review
> > duty) for these CSM components before such duplication:
> >
> > https://edk2.groups.io/g/devel/topic/31627718#40659
> >
> > Would you like to take such role to be the reviewer for the CSM components
> > that will be copied into the OvmfPkg?
> >
> > Thanks in advance.
> 
> Yes, I believe I have sufficient motivation to spend time on that am I
> am willing to do so. My only caveat is that I haven't managed to

Thanks.

> reproduce the working CSM situation that I had when I first implemented
> this all; even by going back to those versions of OVMF + SeaBIOS.
> 
> Lazslo has pointed me at some potential reasons for that, but I haven't
> yet managed to chase them up.

My thought on this is the CSM components in the framework packages are
stable for a period of time. So my guess is that the issue is not directly
related to these components.

Also, if it turns out that there are some missing components left
uncopied, we are able to get them back (from the repo history) and put
them into OvmfPkg then. I can help on that.

Does this sound good to you?

Best Regards,
Hao Wu

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

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



Re: [edk2-devel] [RFC][edk2-platform][Add new packages in Platform\Intel directory]

2019-05-19 Thread Kubacki, Michael A
Hi Liming,

I agree with the need for both packages. We should wait at least another day 
for any additional feedback on the package name GenericBoardPkg. That name may 
give the impression the package can generically be used on various boards 
whereas the intent here is a package containing common or supporting board 
functionality. An alternative name to consider is BoardSupportPkg.

As a reminder, ensure the separation of content follows 8.1 (or update the 
document if necessary):

https://edk2-docs.gitbooks.io/edk-ii-minimum-platform-specification/8_stage_6_advanced_feature_selection/

Thanks,

Michael

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

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



[edk2-devel] [PATCH V2] BaseTools:Update mailing list address in BaseTools error messages

2019-05-19 Thread Fan, ZhijuX
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1815

The edk2 source tree contains four instances of the outdated mailing
list address "edk2-de...@lists.01.org".
I created a new variable, MSG_EDKII_MAIL_ADDR, to receive the
new email address and replaced the old one with this variable

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Common/DataType.py| 1 ++-
 BaseTools/Source/Python/GenFds/GenFds.py  | 2 +-
 BaseTools/Source/Python/Trim/Trim.py  | 2 +-
 BaseTools/Source/Python/UPT/InstallPkg.py | 2 +-
 BaseTools/Source/Python/UPT/InventoryWs.py| 2 +-
 BaseTools/Source/Python/UPT/Logger/StringTable.py | 3 ++-
 BaseTools/Source/Python/UPT/MkPkg.py  | 2 +-
 BaseTools/Source/Python/UPT/ReplacePkg.py | 2 +-
 BaseTools/Source/Python/UPT/RmPkg.py  | 2 +-
 BaseTools/Source/Python/UPT/TestInstall.py| 2 +-
 BaseTools/Source/Python/build/build.py| 2 +-
 11 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/BaseTools/Source/Python/Common/DataType.py 
b/BaseTools/Source/Python/Common/DataType.py
index 780711bf8e..873bd4c9da 100644
--- a/BaseTools/Source/Python/Common/DataType.py
+++ b/BaseTools/Source/Python/Common/DataType.py
@@ -88,6 +88,7 @@ EDK_COMPONENT_TYPE_SAL_RT_DRIVER = 'SAL_RT_DRIVER'
 EDK_COMPONENT_TYPE_APPLICATION = 'APPLICATION'
 EDK_NAME = 'EDK'
 EDKII_NAME = 'EDKII'
+MSG_EDKII_MAIL_ADDR = 'devel@edk2.groups.io'
 
 COMPONENT_TO_MODULE_MAP_DICT = {
 EDK_COMPONENT_TYPE_LIBRARY   :   SUP_MODULE_BASE,
diff --git a/BaseTools/Source/Python/GenFds/GenFds.py 
b/BaseTools/Source/Python/GenFds/GenFds.py
index 21ae9c4d4c..5888997761 100644
--- a/BaseTools/Source/Python/GenFds/GenFds.py
+++ b/BaseTools/Source/Python/GenFds/GenFds.py
@@ -388,7 +388,7 @@ def GenFdsApi(FdsCommandDict, WorkSpaceDataBase=None):
 "\nPython",
 CODE_ERROR,
 "Tools code failure",
-ExtraData="Please send email to edk2-de...@lists.01.org 
for help, attaching following call stack trace!\n",
+ExtraData="Please send email to %s for help, attaching 
following call stack trace!\n" % MSG_EDKII_MAIL_ADDR,
 RaiseError=False
 )
 EdkLogger.quiet(traceback.format_exc())
diff --git a/BaseTools/Source/Python/Trim/Trim.py 
b/BaseTools/Source/Python/Trim/Trim.py
index 6f29f1a35a..43119bd7ff 100644
--- a/BaseTools/Source/Python/Trim/Trim.py
+++ b/BaseTools/Source/Python/Trim/Trim.py
@@ -533,7 +533,7 @@ def Main():
 "\nTrim",
 CODE_ERROR,
 "Unknown fatal error when trimming [%s]" % InputFile,
-ExtraData="\n(Please send email to edk2-de...@lists.01.org 
for help, attaching following call stack trace!)\n",
+ExtraData="\n(Please send email to %s for help, attaching 
following call stack trace!)\n" % MSG_EDKII_MAIL_ADDR,
 RaiseError=False
 )
 EdkLogger.quiet("(Python %s on %s) " % (platform.python_version(), 
sys.platform) + traceback.format_exc())
diff --git a/BaseTools/Source/Python/UPT/InstallPkg.py 
b/BaseTools/Source/Python/UPT/InstallPkg.py
index 6cb9f2533d..e4c7565441 100644
--- a/BaseTools/Source/Python/UPT/InstallPkg.py
+++ b/BaseTools/Source/Python/UPT/InstallPkg.py
@@ -547,7 +547,7 @@ def Main(Options = None):
 "\nInstallPkg",
 CODE_ERROR,
 ST.ERR_UNKNOWN_FATAL_INSTALL_ERR % Options.PackageFile,
-ExtraData=ST.MSG_SEARCH_FOR_HELP,
+ExtraData=ST.MSG_SEARCH_FOR_HELP % ST.MSG_EDKII_MAIL_ADDR,
 RaiseError=False
 )
 Logger.Quiet(ST.MSG_PYTHON_ON % (python_version(),
diff --git a/BaseTools/Source/Python/UPT/InventoryWs.py 
b/BaseTools/Source/Python/UPT/InventoryWs.py
index 778c139edc..955b2e510e 100644
--- a/BaseTools/Source/Python/UPT/InventoryWs.py
+++ b/BaseTools/Source/Python/UPT/InventoryWs.py
@@ -99,7 +99,7 @@ def Main(Options = None):
 Logger.Error("\nInventoryWs",
 CODE_ERROR,
 ST.ERR_UNKNOWN_FATAL_INVENTORYWS_ERR,
-ExtraData=ST.MSG_SEARCH_FOR_HELP,
+ExtraData=ST.MSG_SEARCH_FOR_HELP % ST.MSG_EDKII_MAIL_ADDR,
 RaiseError=False
 )
 Logger.Quiet(ST.MSG_PYTHON_ON % (python_version(),
diff --git a/BaseTools/Source/Python/UPT/Logger/StringTable.py 
b/BaseTools/Source/Python/UPT/Logger/StringTable.py
index 59f71d390b..cc3f2826c0 100644
--- a/BaseTools/Source/Python/UPT/Logger/StringTable.py
+++ b/BaseTools/Source/Python/UPT/Logger/StringTable.py
@@ -316,8 +316,9 @@ MSG_NEW_FILE_NAME_FOR_DIST  = _(
 "Provide new filename for distribution file to be saved:\n")
 MSG_UPDATE_PACKAGE_DATABASE= _("Update Distribution Package 

[edk2-devel] Reviewer for the possible duplicated CSM components in OvmfPkg

2019-05-19 Thread Wu, Hao A
Hello David,

According to the request in a previous mail discussion thread
'Drop CSM support in OvmfPkg?':

https://edk2.groups.io/g/devel/topic/30916686#35723

We plan to duplicate the required CSM modules into the OvmfPkg/Csm folder,
so that those modules will be kept within the edk2 repo.

Meanwhile, Laszlo suggested me to first figure out the ownership (review
duty) for these CSM components before such duplication:

https://edk2.groups.io/g/devel/topic/31627718#40659

Would you like to take such role to be the reviewer for the CSM components
that will be copied into the OvmfPkg?

Thanks in advance.

Best Regards,
Hao Wu



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

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



Re: [edk2-devel] [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

2019-05-19 Thread Zeng, Star
Actually, I agree with you.
Personally, I think more rigorous flow could be like below.

1.   Clear B_GMCD_REG_TE, wait B_GSTS_REG_TE to be cleared.

2.   Set B_GMCD_REG_SRTP, wait B_GSTS_REG_RTPS to be set.

3.   Zero R_RTADDR_REG.

Not sure original code developer Jiewen’s thought about this.


You may submit Bugzilla at https://bugzilla.tianocore.org if you wait.


Thanks,
Star

From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 7:28 PM
To: Zeng, Star ; edk2-de...@lists.01.org; 
devel@edk2.groups.io
Cc: Yao, Jiewen ; Ni, Ray 
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code

Got it! Thanks for your reply.
But you should still poll the B_GSTS_REG_TE bit, not the B_GSTS_REG_RTPS bit, 
in the judgement code of while() loop.
After & operation between Reg32 and B_GSTS_REG_RTPS, the status of 
B_GSTS_REG_TE will be lost.

A more tedious but more reliable operation sequence is recommended in Vt-d 
specification 2.4 below:

to update a bit field in this register at offset X with value of Y, software
must follow below steps:
1. Tmp = Read GSTS_REG
2. Status = (Tmp & 96FFh) // Reset the one-shot bits
3. Command = (Status | (Y << X))
4. Write Command to GCMD_REG
5. Wait until GSTS_REG[X] indicates command is serviced.
发件人: Zeng, Star [mailto:star.z...@intel.com]
发送时间: 2019年5月13日 18:54
收件人: Jerry Zhou(BJ-RD); edk2-de...@lists.01.org
抄送: Yao, Jiewen; Ni, Ray; Zeng, Star
主题: RE: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source code

Good question, my understanding is setting B_GMCD_REG_SRTP(BIT30) ONLY also 
means clearing B_GMCD_REG_TE (BIT31).

Thanks,
Star
From: Jerry Zhou(BJ-RD) [mailto:jerryz...@zhaoxin.com]
Sent: Monday, May 13, 2019 10:59 AM
To: Zeng, Star mailto:star.z...@intel.com>>; 
edk2-de...@lists.01.org
Cc: Yao, Jiewen mailto:jiewen@intel.com>>; Ni, Ray 
mailto:ray...@intel.com>>
Subject: 答复: [edk2] [PATCH] IntelSiliconPkg VTdDxe: a question about the source 
code


Hi Star,

 I'am so interested in DMA protection in UEFI. It's a really good 
design!

 But I have a question about the implemention of DisableDmar() in 
IntelSiliconPkg\feature\vtd\intelvtddxe\VtdReg.c

 Is it a typing error in the code segment below?



//

// Disable VTd

//

MmioWrite32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + R_GCMD_REG, 
B_GMCD_REG_SRTP);

do {

  Reg32 = MmioRead32 (mVtdUnitInformation[Index].VtdUnitBaseAddress + 
R_GSTS_REG);

} while((Reg32 & B_GSTS_REG_RTPS) == 0);



The software should program the B_GMCD_REG_TE field in global command register 
and then poll the B_GSTS_REG_TE field in global status register if the DMAR is 
expected to be disabled or enabled according to Vt-d specification.



Thanks

Jerry Zhou

Ext:892418







-邮件原件-
发件人: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] 代表 Star Zeng
发送时间: 2018年10月24日 11:32
收件人: edk2-de...@lists.01.org
抄送: Jiewen Yao; Star Zeng
主题: [edk2] [PATCH] IntelSiliconPkg VTdDxe: Option to force no early access attr 
request



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



To have high confidence in usage for platform, add option (BIT2 of

PcdVTdPolicyPropertyMask) to force no IOMMU access attribute request

recording before DMAR table is installed.



Check PcdVTdPolicyPropertyMask BIT2 before RequestAccessAttribute()

and ProcessRequestedAccessAttribute(), then RequestAccessAttribute(),

ProcessRequestedAccessAttribute() and mAccessRequestXXX variables

could be optimized by compiler when PcdVTdPolicyPropertyMask BIT2 = 1.



Test done:

1: Created case that has IOMMU access attribute request before DMAR

   table is installed, ASSERT was triggered after setting

   PcdVTdPolicyPropertyMask BIT2 to 1.



2. Confirmed RequestAccessAttribute(), ProcessRequestedAccessAttribute()

   and mAccessRequestXXX variables were optimized by compiler after

   setting PcdVTdPolicyPropertyMask BIT2 to 1.



Cc: Jiewen Yao mailto:jiewen@intel.com>>

Cc: Rangasai V Chaganty 
mailto:rangasai.v.chaga...@intel.com>>

Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Star Zeng mailto:star.z...@intel.com>>

---

IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c | 8 +++-

IntelSiliconPkg/Feature/VTd/IntelVTdDxe/IntelVTdDxe.c   | 7 +++

IntelSiliconPkg/IntelSiliconPkg.dec | 1 +

3 files changed, 15 insertions(+), 1 deletion(-)



diff --git a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c 
b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c

index 86d50eb6f288..7784545631b3 100644

--- a/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c

+++ b/IntelSiliconPkg/Feature/VTd/IntelVTdDxe/DmaProtection.c

@@ -515,7 +515,13 @@ SetupVtd (



   ParseDmarAcpiTableRmrr ();



-  ProcessRequestedAccessAttribute ();

+  if ((PcdGet8 (PcdVTdPolicyP

Re: [edk2-devel] [Patch 3/3] MdeModulePkg: Remove network library header file from package DEC file

2019-05-19 Thread Wu, Hao A
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, May 15, 2019 8:02 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A
> Subject: [Patch 3/3] MdeModulePkg: Remove network library header file from
> package DEC file
> 
> Signed-off-by: Liming Gao 
> Cc: Hao A Wu 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 23 ---
>  1 file changed, 23 deletions(-)

Bisect seems not considered here.

I think it is fine, so:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu

> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index b2fab4a65e..1859dfbcb3 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -25,26 +25,6 @@ [Includes]
> 
> 
>  [LibraryClasses]
> -  ##  @libraryclass  IpIo layer upon EFI IP4 Protocol.
> -  #   This library is only intended to be used by UEFI network stack modules.
> -  IpIoLib|Include/Library/IpIoLib.h
> -
> -  ##  @libraryclass  Basic function for UEFI network stack.
> -  #   This library is only intended to be used by UEFI network stack modules.
> -  NetLib|Include/Library/NetLib.h
> -
> -  ##  @libraryclass  The helper routines to access UDP service.
> -  #   This library is only intended to be used by UEFI network stack modules.
> -  UdpIoLib|Include/Library/UdpIoLib.h
> -
> -  ##  @libraryclass  The helper routines to access TCP service.
> -  #   This library is only intended to be used by UEFI network stack modules.
> -  TcpIoLib|Include/Library/TcpIoLib.h
> -
> -  ##  @libraryclass  The helper routines to access HTTP service.
> -  #   This library is only intended to be used by UEFI network stack modules.
> -  HttpLib|Include/Library/HttpLib.h
> -
>##  @libraryclass  Defines a set of methods to reset whole system.
>ResetSystemLib|Include/Library/ResetSystemLib.h
> 
> @@ -67,9 +47,6 @@ [LibraryClasses]
>##  @libraryclass  Defines a set of interfaces on how to process capusle
> image update.
>CapsuleLib|Include/Library/CapsuleLib.h
> 
> -  ##  @libraryclass  Library for Deferred Procedure Calls.
> -  DpcLib|Include/Library/DpcLib.h
> -
>##  @libraryclassProvides global variables that are pointers
>#   to the UEFI HII related protocols.
>#
> --
> 2.13.0.windows.1


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

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



Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b

2019-05-19 Thread Gary Lin
On Sat, May 18, 2019 at 07:26:35AM +, Xiaoyu Lu wrote:
> Gary Lin,
> 
>   Because I divided commit(PATCH v4 6/7) into two patches. Can I pick 
> your Tested-by tag for the two patches?
> 
If there is no functional change, my "Tested-by" is still valid.
I can do the test again for v5 if you like.
BTW, I forgot to state that my "Tested-by" doesn't include "PATCH v4 5/7"
since I didn't build aarch64 aavmf due to lacking of https support.

Thanks,

Gary Lin

> Thanks
> Xiaoyu
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gary Lin
> Sent: Friday, May 17, 2019 5:17 PM
> To: devel@edk2.groups.io; Lu, XiaoyuX 
> Cc: Laszlo Ersek ; Wang, Jian J ; 
> Ye, Ting 
> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b
> 
> On Thu, May 16, 2019 at 03:54:51AM -0400, Xiaoyu lu wrote:
> > This series is also available at:
> > https://github.com/xiaoyuxlu/edk2/tree/bz_1089_upgrade_to_openssl_1_1_
> > 1b_v4
> > 
> > Changes:
> > 
> > (1) CryptoPkgOpensslLib: Modify process_files.pl for  upgrading 
> > OpenSSL
> > 
> > (2) CryptoPkg/OpensslLib: Exclude unnecessary files in process_files.pl
> > crypto/store/* are excluded.
> > crypto/rand/randfile.c is excluded.
> > 
> > (3) CryptoPkg/IntrinsicLib: Fix possible unresolved external symbol 
> > issue
> > 
> > (4) CryptoPkg/OpensslLib: Prepare for upgrading OpenSSL
> > Disable warnings for buiding OpenSSL_1_1_1b
> > 
> > (5) CryptoPkg/OpensslLib: Fix cross-build problem for AARCH64
> > 
> > (6) CryptoPkg: Upgrade OpenSSL to 1.1.1b
> > The biggest change is use TSC as entropy source
> > If TSC isn't avaiable, fallback to TimerLib(PerformanceCounter).
> > 
> > (7) CryptoPkg/BaseCryptLib: Make HMAC_CTX size backward compatible
> > 
> > 
> > Verification done for this series:
> > * Https boot in OvmfPkg.
> > * BaseCrypt Library test. (Ovmf, EmulatorPkg)
> > 
> My https boot test with ovmf looks good. The connection was rejected as 
> expected when the server certificate wasn't enrolled. The bootloader images 
> were downloaded after adding the certificate, and I can boot into the 
> installation UI in the end.
> 
> I skipped the test for aavmf since TLS is still not enabled.
> 
> For the series.
> Tested-by: Gary Lin 
> 
> > Important notice:
> > Nt32Pkg doesn't support TimerLib
> > > TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTem
> > > TimerLib|plate.inf
> > So it will failed in Nt32Pkg.
> > 
> > Cc: Jian J Wang 
> > Cc: Ting Ye 
> > 
> > Laszlo Ersek (1):
> >   CryptoPkg/OpensslLib: Fix cross-build problem for AARCH64
> > 
> > Xiaoyu Lu (6):
> >   CryptoPkg/OpensslLib: Modify process_files.pl for upgrading OpenSSL
> >   CryptoPkg/OpensslLib: Exclude unnecessary files in process_files.pl
> >   CryptoPkg/IntrinsicLib: Fix possible unresolved external symbol issue
> >   CryptoPkg/OpensslLib: Prepare for upgrading OpenSSL
> >   CryptoPkg: Upgrade OpenSSL to 1.1.1b
> >   CryptoPkg/BaseCryptLib: Make HMAC_CTX size backward compatible
> > 
> >  CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf|   4 +-
> >  CryptoPkg/Library/OpensslLib/OpensslLib.inf|  76 -
> >  CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf  |  67 -
> >  CryptoPkg/Library/Include/CrtLibSupport.h  |  13 +-
> >  CryptoPkg/Library/Include/openssl/opensslconf.h|  54 +++-
> >  CryptoPkg/Library/Include/sys/syscall.h|  11 +
> >  CryptoPkg/Library/OpensslLib/buildinf.h|   2 +
> >  CryptoPkg/Library/OpensslLib/rand_pool_noise.h |  29 ++
> >  CryptoPkg/Library/BaseCryptLib/Hmac/CryptHmacMd5.c |   8 +-
> >  .../Library/BaseCryptLib/Hmac/CryptHmacSha1.c  |   9 +-
> >  .../Library/BaseCryptLib/Hmac/CryptHmacSha256.c|   8 +-
> >  CryptoPkg/Library/IntrinsicLib/Ia32/MathFtol.c |  22 ++
> >  CryptoPkg/Library/OpensslLib/ossl_store.c  |  17 ++
> >  CryptoPkg/Library/OpensslLib/rand_pool.c   | 316 
> > +
> >  CryptoPkg/Library/OpensslLib/rand_pool_noise.c |  29 ++
> >  CryptoPkg/Library/OpensslLib/rand_pool_noise_tsc.c |  43 +++
> >  CryptoPkg/Library/OpensslLib/openssl   |   2 +-
> >  CryptoPkg/Library/OpensslLib/process_files.pl  |  11 +-
> >  18 files changed, 669 insertions(+), 52 deletions(-)  create mode 
> > 100644 CryptoPkg/Library/Include/sys/syscall.h
> >  create mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise.h
> >  create mode 100644 CryptoPkg/Library/IntrinsicLib/Ia32/MathFtol.c
> >  create mode 100644 CryptoPkg/Library/OpensslLib/ossl_store.c
> >  create mode 100644 CryptoPkg/Library/OpensslLib/rand_pool.c
> >  create mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise.c
> >  create mode 100644 CryptoPkg/Library/OpensslLib/rand_pool_noise_tsc.c
> > 
> > --
> > 2.7.4
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
> 
> 

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

View/Reply Online (#40989): https://edk2.groups.io/g/devel/me

Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b

2019-05-19 Thread Wang, Jian J
Ard,


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ard
> Biesheuvel
> Sent: Friday, May 17, 2019 11:06 PM
> To: Laszlo Ersek 
> Cc: Wang, Jian J ; devel@edk2.groups.io; Lu, XiaoyuX
> ; Ye, Ting ; Leif Lindholm
> ; Gao, Liming 
> Subject: Re: [edk2-devel] [PATCH v4 0/7] CryptoPkg: Upgrade OpenSSL to 1.1.1b
> 
> On Fri, 17 May 2019 at 15:17, Laszlo Ersek  wrote:
> >
> > On 05/17/19 15:04, Laszlo Ersek wrote:
> > > On 05/17/19 07:11, Wang, Jian J wrote:
> > >> Hi Laszlo,
> > >>
> > >> There's already a float library used in OpensslLib.inf.
> > >>
> > >> [LibraryClasses.ARM]
> > >>   ArmSoftFloatLib
> > >>
> > >> The problem is that the below instance doesn't implement __aeabi_ui2d
> > >> and __aeabi_d2uiz (I encountered this one as well)
> > >>
> > >>   ArmPkg\Library\ArmSoftFloatLib\ArmSoftFloatLib.inf
> > >>
> > >> I think we can update this library support those two APIs. So what about
> > >> we still push the patch and file a BZ to fix this issue?
> > >
> > > I'm OK with that, but it will break ARM and AARCH64 platforms that
> > > consume OpensslLib (directly or through BaseCryptLib), so this question
> > > is up to Leif and Ard to decide.
> >
> > Correction: break ARM platforms only, not AARCH64.
> >
> 
> We obviously need to fix this before we can upgrade to a new OpenSSL version.
> 
> Do we really have a need for the random functions? These seem the only
> ones that use floating point, which the UEFI spec does not permit, so
> it would be better if we could fix this by removing the dependency on
> FP in the first place (and get rid of ArmSoftFloatLib entirely)
> 

BaseCryptLib provides RandSeed/RandBytes interface which wrap openssl rand
functionalities. These interfaces are used by following components in edk2

  - CryptoPkg\Library\TlsLib\TlsInit.c
  - SecurityPkg\HddPassword\HddPasswordDxe.c

Openssl components, like asn1, bn, evp, ocsp, pem, pkcs7, pkcs12, rsa, ssl (in 
addition
to cms, dsa, srp, which are disabled in edk2) will call rand_* interface as 
well.

Regards,
Jian

> 


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

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



Re: [edk2-devel] [Patch 1/2] ShellPkg: Update DSC to use NetworkPkg's include fragment file

2019-05-19 Thread Gao, Zhichao
Reviewed-by: Zhichao Gao 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Liming Gao
> Sent: Friday, May 17, 2019 4:51 PM
> To: devel@edk2.groups.io
> Cc: Gao, Zhichao ; Ni, Ray ;
> Carsey, Jaben 
> Subject: [edk2-devel] [Patch 1/2] ShellPkg: Update DSC to use NetworkPkg's
> include fragment file
> 
> Signed-off-by: Liming Gao 
> Cc: Zhichao Gao 
> Cc: Ray Ni 
> Cc: Jaben Carsey 
> ---
>  ShellPkg/ShellPkg.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc index
> 50d9bbb235..6a139b3b91 100644
> --- a/ShellPkg/ShellPkg.dsc
> +++ b/ShellPkg/ShellPkg.dsc
> @@ -40,7 +40,7 @@ [LibraryClasses.common]
> 
> UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib
> /UefiRuntimeServicesTableLib.inf
> 
> UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiService
> sLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> -  NetLib|MdeModulePkg/Library/DxeNetLib/DxeNetLib.inf
> +  !include NetworkPkg/NetworkLibs.dsc.inc
> 
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> 
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellComma
> ndLib.inf
> --
> 2.13.0.windows.1
> 
> 
> 


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

View/Reply Online (#40987): https://edk2.groups.io/g/devel/message/40987
Mute This Topic: https://groups.io/mt/31653118/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: Add reviewer for Platform/Intel packages

2019-05-19 Thread Kubacki, Michael A
Reviewed-by: Michael Kubacki 

> -Original Message-
> From: Gao, Liming
> Sent: Sunday, May 19, 2019 4:47 AM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A 
> Subject: [Patch] Maintainers.txt: Add reviewer for Platform/Intel packages
> 
> Add Liming Gao as the reviewer for Platform/Intel MinPlatformPkg and
> AdvancedFeaturePkg
> 
> Signed-off-by: Liming Gao 
> Cc: Michael Kubacki 
> ---
>  Maintainers.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt index c16471b72f..cf3ede7f0a
> 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -58,6 +58,7 @@ M: Yi Qian 
> Platform/Intel/AdvancedFeaturePkg
>  M: Michael Kubacki 
>  M: Sai Chaganty 
> +R: Liming Gao 
> 
>  Platform/Intel/ClevoOpenBoardPkg
>  M: Michael Kubacki  @@ -71,6 +72,7 @@
> M: Michael Kubacki 
> Platform/Intel/MinPlatformPkg
>  M: Michael Kubacki 
>  R: Chasel Chiu 
> +R: Liming Gao 
> 
>  Platform/Intel/PurleyOpenBoardPkg
>  M: Shifei A Lu 
> --
> 2.13.0.windows.1


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

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



Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8

2019-05-19 Thread Jordan Justen
On 2019-04-27 17:55:02, Liming Gao wrote:
> >-Original Message-
> >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >Sent: Saturday, April 27, 2019 12:33 AM
> >
> >
> >This series confuses me. The existing CLANGxx toolchains already use
> >GenFw and ELF to PE/COFF conversion, so the name CLANG8ELF is
> >misleading.
> >
> LLVM/CLANG8.0 compiler supports to generate PE image or ELF image.
> This tool chain is to generate ELF image and be converted to PE
> image. I am investigating another tool chain with CLANG8.0 to
> directly generate PE image. To differentiate them, I use the tool
> chain name CLANG8ELF and CLANG8PE for them.

Assuming CLANG8ELF and CLANG8PE were functional, would both be needed?
It kind of sounds like this a half-finished investigation.

I'm guessing that if CLANG8PE produces equal or better code, then it
would be preferred.

Therefore, shouldn't we just finish the investigation, and add a
single CLANG8 toolchain at the end? Or, maybe to reflect that it
mostly uses the LLVM tool stack we could name it LLVM8.

-Jordan

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

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



Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain

2019-05-19 Thread Liming Gao
Ard:
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, May 19, 2019 9:24 PM
> To: edk2-devel-groups-io ; Gao, Liming 
> 
> Subject: Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support 
> CLANG8ELF tool chain
> 
> On Fri, 26 Apr 2019 at 16:43, Liming Gao  wrote:
> >
> > Signed-off-by: Liming Gao 
> > ---
> >  OvmfPkg/OvmfPkgIa32.dsc| 4 +++-
> >  OvmfPkg/OvmfPkgIa32.fdf| 2 +-
> >  OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
> >  OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
> >  OvmfPkg/OvmfPkgX64.dsc | 4 +++-
> >  OvmfPkg/OvmfPkgX64.fdf | 2 +-
> >  6 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> > index 98a8467e86..7972b25112 100644
> > --- a/OvmfPkg/OvmfPkgIa32.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32.dsc
> > @@ -73,12 +73,14 @@
> >
> >  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> 
> So are we introducing a new toolchain family just for the linker
> flags? In that case, it would be better to call the toolchain family
> CLANGLLD or LLVMLLD.

This is the tool chain BUILDRULEFAMILY, not tool chain family. It is for the 
build rule customization. 
I agree CLANGLLD is better. 

> 
> We could also consider switching all GNU ld toolchains to use
> max-page-size instead of common-page-size, given that binutils
> supports both.
> 
Yes. Binutils supports max-page-size option also. But, I don't investigate more 
on 
common-page-size and max-page-size in Binutils. To not impact GCC tool chain, 
I enable max-page-size option first in CLANGLLD tool chain, because CLANG LLD 
only supports it.

> >XCODE:*_*_*_DLINK_FLAGS =
> >
> >  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> > level
> >  # protection of DXE_SMM_DRIVER/SMM_CORE modules
> >  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> > BuildOptions.common.EDKII.SMM_CORE]
> >GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> >XCODE:*_*_*_DLINK_FLAGS =
> >
> >  
> > 
> > @@ -832,7 +834,7 @@
> >OvmfPkg/Csm/Csm16/Csm16.inf
> >  !endif
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> >ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> > index bc08bf2243..2894cfe8d6 100644
> > --- a/OvmfPkg/OvmfPkgIa32.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32.fdf
> > @@ -287,7 +287,7 @@ INF  
> > MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> >  INF  FatPkg/EnhancedFatDxe/Fat.inf
> >  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> >  INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> >  !endif
> >  INF  ShellPkg/Application/Shell/Shell.inf
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> > index 1f722fc987..c9feeafaae 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> > @@ -78,12 +78,14 @@
> >
> >  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> >GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> >XCODE:*_*_*_DLINK_FLAGS =
> >
> >  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> > level
> >  # protection of DXE_SMM_DRIVER/SMM_CORE modules
> >  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> > BuildOptions.common.EDKII.SMM_CORE]
> >GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> > +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
> >XCODE:*_*_*_DLINK_FLAGS =
> >
> >  
> > 
> > @@ -841,7 +843,7 @@
> >OvmfPkg/Csm/Csm16/Csm16.inf
> >  !endif
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
> >ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
> >  
> >gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> > index ccf36c5dd9..affce983f9 100644
> > --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> > @@ -288,7 +288,7 @@ INF  
> > MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
> >  INF  FatPkg/EnhancedFatDxe/Fat.inf
> >  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> >
> > -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> > +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLAN

Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain

2019-05-19 Thread Ard Biesheuvel
On Fri, 26 Apr 2019 at 16:43, Liming Gao  wrote:
>
> Signed-off-by: Liming Gao 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 4 +++-
>  OvmfPkg/OvmfPkgIa32.fdf| 2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
>  OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
>  OvmfPkg/OvmfPkgX64.dsc | 4 +++-
>  OvmfPkg/OvmfPkgX64.fdf | 2 +-
>  6 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 98a8467e86..7972b25112 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -73,12 +73,14 @@
>
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000

So are we introducing a new toolchain family just for the linker
flags? In that case, it would be better to call the toolchain family
CLANGLLD or LLVMLLD.

We could also consider switching all GNU ld toolchains to use
max-page-size instead of common-page-size, given that binutils
supports both.

>XCODE:*_*_*_DLINK_FLAGS =
>
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
>
>  
> 
> @@ -832,7 +834,7 @@
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index bc08bf2243..2894cfe8d6 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -287,7 +287,7 @@ INF  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>  INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  !endif
>  INF  ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1f722fc987..c9feeafaae 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -78,12 +78,14 @@
>
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
>
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
>
>  
> 
> @@ -841,7 +843,7 @@
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -288,7 +288,7 @@ INF  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
>
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>  INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  !endif
>  INF  ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2927ee07b8..f28ec13c0c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -78,12 +78,14 @@
>
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
>
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
>
> 

Re: [edk2-devel] [PATCH edk2-platforms V2 16/16] Platform/PurleyOpenBoardPkg: Update DSC/FDF to use NetworkPkg's fragment file.

2019-05-19 Thread Liming Gao
For the change in 
Platform/Intel/PurleyOpenBoardPkg/BoardMtOlympus/PlatformPkg.dsc, 
Need !include NetworkPkg/NetworkDefines.dsc.inc

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Kubacki, Michael A
> Sent: Friday, May 17, 2019 3:26 PM
> To: Zhang, Shenglei ; devel@edk2.groups.io
> Cc: Yao, Jiewen ; Lu, Shifei A ; 
> Zhou, Bowen 
> Subject: Re: [edk2-devel] [PATCH edk2-platforms V2 16/16] 
> Platform/PurleyOpenBoardPkg: Update DSC/FDF to use NetworkPkg's
> fragment file.
> 
> This looks like a good improvement.
> ---
> * This is touching three packages though the patch only calls out 
> PurleyOpenBoardPkg.
>   * AdvancedFeaturePkg
>   * MinPlatformPkg
>   * Purley OpenBoardPkg
> ---
> * Copyright years in files modified are not updated.
> ---
> There's some PatchCheck.py errors, please check and fix those.
> 
> Thanks,
> Michael
> 
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Friday, May 17, 2019 12:10 AM
> > To: devel@edk2.groups.io
> > Cc: Kubacki, Michael A ; Yao, Jiewen
> > ; Lu, Shifei A ; Zhou, Bowen
> > 
> > Subject: [PATCH edk2-platforms V2 16/16] Platform/PurleyOpenBoardPkg:
> > Update DSC/FDF to use NetworkPkg's fragment file.
> >
> > This patch updates the platform DSC/FDF files to use the include fragment
> > files provided by NetworkPkg.And add network related definition in Purley
> > PlatformPkg.dsc.
> >
> > Cc: Michael A Kubacki 
> > Cc: Jiewen Yao 
> > cc: Shifei A Lu 
> > cc: Xiaohu Zhou 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Shenglei Zhang 
> > ---
> >  .../Include/Dsc/CoreAdvancedDxeInclude.dsc| 26 +--
> >  .../Include/Fdf/CoreAdvancedLateInclude.fdf   | 26 +--
> >  .../Include/Dsc/CoreCommonLib.dsc | 11 
> >  .../BoardMtOlympus/PlatformPkg.dsc|  6 +
> >  4 files changed, 14 insertions(+), 55 deletions(-)
> >
> > diff --git
> > a/Platform/Intel/AdvancedFeaturePkg/Include/Dsc/CoreAdvancedDxeInclud
> > e.dsc
> > b/Platform/Intel/AdvancedFeaturePkg/Include/Dsc/CoreAdvancedDxeInclud
> > e.dsc
> > index 6764d46131..0c44c52582 100644
> > ---
> > a/Platform/Intel/AdvancedFeaturePkg/Include/Dsc/CoreAdvancedDxeInclud
> > e.dsc
> > +++
> > b/Platform/Intel/AdvancedFeaturePkg/Include/Dsc/CoreAdvancedDxeInclu
> > +++ de.dsc
> > @@ -17,31 +17,7 @@
> >#
> ># UEFI network modules
> >#
> > -!if gAdvancedFeaturePkgTokenSpaceGuid.PcdNetworkEnable == TRUE
> > -  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
> > -  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
> > -  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
> > -  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
> > -  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
> > -  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
> > -  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
> > -  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
> > -  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> > -
> > -  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> > -  NetworkPkg/TcpDxe/TcpDxe.inf
> > -  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> > -  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> > -  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> > -
> > -  NetworkPkg/DnsDxe/DnsDxe.inf
> > -  NetworkPkg/HttpDxe/HttpDxe.inf
> > -  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
> > -  NetworkPkg/HttpBootDxe/HttpBootDxe.inf
> > -
> > -  NetworkPkg/IScsiDxe/IScsiDxe.inf
> > -  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> > -!endif
> > +  !include NetworkPkg/NetworkComponents.dsc.inc
> >
> >  !if gAdvancedFeaturePkgTokenSpaceGuid.PcdSmbiosEnable == TRUE
> >MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> > diff --git
> > a/Platform/Intel/AdvancedFeaturePkg/Include/Fdf/CoreAdvancedLateInclud
> > e.fdf
> > b/Platform/Intel/AdvancedFeaturePkg/Include/Fdf/CoreAdvancedLateInclud
> > e.fdf
> > index 64f1dd5872..97706f7805 100644
> > ---
> > a/Platform/Intel/AdvancedFeaturePkg/Include/Fdf/CoreAdvancedLateInclud
> > e.fdf
> > +++
> > b/Platform/Intel/AdvancedFeaturePkg/Include/Fdf/CoreAdvancedLateIncl
> > +++ ude.fdf
> > @@ -17,31 +17,7 @@
> >  #
> >  # UEFI network modules
> >  #
> > -!if gAdvancedFeaturePkgTokenSpaceGuid.PcdNetworkEnable == TRUE -INF
> > MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
> > -INF  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
> > -INF  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
> > -INF  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
> > -INF  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
> > -INF  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
> > -INF  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
> > -INF  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
> > -INF  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
> > -
> > -INF  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> > -INF  NetworkPkg/TcpDxe/TcpDxe.inf
> > -INF  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> > -INF  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> > -INF  NetworkPkg/Mtftp6Dxe/

Re: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support CLANG8ELF tool chain

2019-05-19 Thread Liming Gao
Cc to OvmfPkg maintainers. Please help review this change. 

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Liming 
> Gao
> Sent: Friday, April 26, 2019 10:43 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [Patch 7/7] OvmfPkg: Update DSC/FDF to support 
> CLANG8ELF tool chain
> 
> Signed-off-by: Liming Gao 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 4 +++-
>  OvmfPkg/OvmfPkgIa32.fdf| 2 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc | 4 +++-
>  OvmfPkg/OvmfPkgIa32X64.fdf | 2 +-
>  OvmfPkg/OvmfPkgX64.dsc | 4 +++-
>  OvmfPkg/OvmfPkgX64.fdf | 2 +-
>  6 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 98a8467e86..7972b25112 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -73,12 +73,14 @@
> 
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
> 
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
> 
>  
> 
> @@ -832,7 +834,7 @@
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
> 
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index bc08bf2243..2894cfe8d6 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -287,7 +287,7 @@ INF  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> 
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>  INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  !endif
>  INF  ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1f722fc987..c9feeafaae 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -78,12 +78,14 @@
> 
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
> 
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
> 
>  
> 
> @@ -841,7 +843,7 @@
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
> 
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
>  
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index ccf36c5dd9..affce983f9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -288,7 +288,7 @@ INF  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResour
>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>  INF  MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
> 
> -!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +!if $(TOOL_CHAIN_TAG) != "XCODE5" AND $(TOOL_CHAIN_TAG) != "CLANG8ELF"
>  INF  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
>  !endif
>  INF  ShellPkg/Application/Shell/Shell.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 2927ee07b8..f28ec13c0c 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -78,12 +78,14 @@
> 
>  [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*_DLINK_FLAGS =
> 
>  # Force PE/COFF sections to be aligned at 4KB boundaries to support page 
> level
>  # protection of DXE_SMM_DRIVER/SMM_CORE modules
>  [BuildOptions.common.EDKII.DXE_SMM_DRIVER, 
> BuildOptions.common.EDKII.SMM_CORE]
>GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
> +  CLANGGCC:*_*_*_DLINK_FLAGS = -z max-page-size=0x1000
>XCODE:*_*_*

[edk2-devel] [Patch] Maintainers.txt: Add reviewer for Platform/Intel packages

2019-05-19 Thread Liming Gao
Add Liming Gao as the reviewer for Platform/Intel
MinPlatformPkg and AdvancedFeaturePkg

Signed-off-by: Liming Gao 
Cc: Michael Kubacki 
---
 Maintainers.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index c16471b72f..cf3ede7f0a 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -58,6 +58,7 @@ M: Yi Qian 
 Platform/Intel/AdvancedFeaturePkg
 M: Michael Kubacki 
 M: Sai Chaganty 
+R: Liming Gao 
 
 Platform/Intel/ClevoOpenBoardPkg
 M: Michael Kubacki 
@@ -71,6 +72,7 @@ M: Michael Kubacki 
 Platform/Intel/MinPlatformPkg
 M: Michael Kubacki 
 R: Chasel Chiu 
+R: Liming Gao 
 
 Platform/Intel/PurleyOpenBoardPkg
 M: Shifei A Lu 
-- 
2.13.0.windows.1


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

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