Date   

Re: [PATCH v1 0/3] EmbeddedPkg: Enable CI

Ard Biesheuvel
 

On Fri, 23 Sept 2022 at 03:09, Michael Kubacki
<mikuback@...> wrote:

What are the next steps?
As long as we are using the most lenient setting, I'm ok with this

Acked-by: Ard Biesheuvel <ardb@...>


On 9/15/2022 5:54 PM, Kinney, Michael D wrote:
Hi Ard,

If there is content you do not think needs to follow the min quality criteria, perhaps it can be moved out of edk2 repo? Maybe to edk2-staging or edk2-archive?

Thanks,

Mike

-----Original Message-----
From: Ard Biesheuvel <ardb@...>
Sent: Thursday, September 15, 2022 2:03 PM
To: Kinney, Michael D <michael.d.kinney@...>
Cc: Michael Kubacki <mikuback@...>; devel@edk2.groups.io; Leif Lindholm <quic_llindhol@...>; Ard
Biesheuvel <ardb+tianocore@...>; Abner Chang <abner.chang@...>; Daniel Schaefer <git@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] EmbeddedPkg: Enable CI

On Thu, 15 Sept 2022 at 22:52, Kinney, Michael D
<michael.d.kinney@...> wrote:

Ard,

Why would you want to do that? The whole point of CI is to establish a minimum quality level for all code in the project.

They can be disabled with updates to the YAML file. Checks can be disabled completely and may of the checks support
exception lists.
If the only way to prevent this from happening is to turn it off again
in the YAML file, I'd prefer not to turn it on to begin with.

I agree that code quality is important, but IMO the checks we have at
the moment are way too strict, and 90% of the time I spend on
reviewing and merging patches is on crustify and patchcheck errors.
This is simply not worth my time.


Re: [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native instruction support for IA32

Yao, Jiewen
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao,
Jiewen
Sent: Friday, September 23, 2022 6:34 PM
To: devel@edk2.groups.io; christopher.zurcher@...; Christopher
Zurcher <zurcher@...>
Cc: Li, Yi1 <yi1.li@...>; Wang, Jian J <jian.j.wang@...>; Lu,
Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native
instruction support for IA32

Thank you very much!

Reviewed-by: Jiewen Yao <jiewe.yao@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Christopher Zurcher
Sent: Thursday, September 22, 2022 9:45 AM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@...>;
Christopher Zurcher <zurcher@...>
Cc: Li, Yi1 <yi1.li@...>; Wang, Jian J <jian.j.wang@...>; Lu,
Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] CryptoPkg/OpensslLib: Add
native
instruction support for IA32

I have verified performance gains and functional integrity in SHA256,
SHA384, and SHA512 hashing as well as AES encryption on Intel hardware
as well as QEMU. The assembly implementations included with this patch
are limited to SHA and AES to reduce size impact, and to match the
currently-available accelerations in the X64 equivalent library. These flows
have also been validated on in-market hardware. Previous benchmarking
of
this code demonstrated a 12x speed improvement for SHA256 compared
to
the base algorithm.

Thanks,
Christopher Zurcher

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao,
Jiewen
Sent: Wednesday, September 21, 2022 17:54
To: Christopher Zurcher <zurcher@...>; devel@edk2.groups.io
Cc: Li, Yi1 <yi1.li@...>; Wang, Jian J <jian.j.wang@...>; Lu,
Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin
<guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] CryptoPkg/OpensslLib: Add
native
instruction support for IA32

Thanks.
Would you please add more detailed description on what test you have
done?

e.g. Real platform? Unit Test? Etc.

-----Original Message-----
From: Christopher Zurcher <zurcher@...>
Sent: Thursday, September 22, 2022 4:26 AM
To: devel@edk2.groups.io
Cc: Li, Yi1 <yi1.li@...>; Yao, Jiewen <jiewen.yao@...>;
Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native instruction
support for IA32

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3654
PR: https://github.com/tianocore/edk2/pull/3352

This patch adds support for building the native instruction algorithms
for the IA32 architecture in OpensslLib. The base variant has been
tested with VS2019 and CLANGPDB toolchains, and a GCC variant is also
provided.

The implementation here follows the previous implementation of X64
native instructions as committed in 878a92a887.

Cc: Yi Li <yi1.li@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>

Christopher Zurcher (3):
CryptoPkg/OpensslLib: Add native instruction support for IA32
CryptoPkg/OpensslLib: Commit the auto-generated assembly files for
IA32
CryptoPkg/OpensslLib: Update generated files for native X64

CryptoPkg/CryptoPkg.ci.yaml | 4 +
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/aesni-x86.nasm |
3212
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/vpaes-x86.nasm |
651
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/modes/ghash-x86.nasm |
700
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha1-586.nasm |
1394
++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha256-586.nasm |
3364
++++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha512-586.nasm |
579
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/x86cpuid.nasm | 433
+++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/aesni-x86.S |
3247
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/vpaes-x86.S | 670
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/modes/ghash-x86.S |
703
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha1-586.S |
1389
++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha256-586.S |
3356
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha512-586.S |
574
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/x86cpuid.S | 449
+++
CryptoPkg/Library/OpensslLib/OpensslLibIa32.inf | 699 ++++
CryptoPkg/Library/OpensslLib/OpensslLibIa32Gcc.inf | 699 ++++
CryptoPkg/Library/OpensslLib/OpensslLibX64.inf | 53 +
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf | 53 +
CryptoPkg/Library/OpensslLib/UefiAsm.conf | 18 +
CryptoPkg/Library/OpensslLib/process_files.pl | 12 +
21 files changed, 22259 insertions(+) create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/aesni-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/vpaes-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/modes/ghash-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha1-
586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha256-586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha512-586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/x86cpuid.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/aesni-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/vpaes-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/modes/ghash-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha1-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha256-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha512-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/x86cpuid.S
create mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibIa32.inf
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibIa32Gcc.inf

--
2.29.2.windows.2












Re: [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native instruction support for IA32

Yao, Jiewen
 

Thank you very much!

Reviewed-by: Jiewen Yao <jiewe.yao@...>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Christopher Zurcher
Sent: Thursday, September 22, 2022 9:45 AM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@...>;
Christopher Zurcher <zurcher@...>
Cc: Li, Yi1 <yi1.li@...>; Wang, Jian J <jian.j.wang@...>; Lu,
Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native
instruction support for IA32

I have verified performance gains and functional integrity in SHA256,
SHA384, and SHA512 hashing as well as AES encryption on Intel hardware
as well as QEMU. The assembly implementations included with this patch
are limited to SHA and AES to reduce size impact, and to match the
currently-available accelerations in the X64 equivalent library. These flows
have also been validated on in-market hardware. Previous benchmarking of
this code demonstrated a 12x speed improvement for SHA256 compared to
the base algorithm.

Thanks,
Christopher Zurcher

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao,
Jiewen
Sent: Wednesday, September 21, 2022 17:54
To: Christopher Zurcher <zurcher@...>; devel@edk2.groups.io
Cc: Li, Yi1 <yi1.li@...>; Wang, Jian J <jian.j.wang@...>; Lu,
Xiaoyu1 <xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: Re: [edk2-devel] [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native
instruction support for IA32

Thanks.
Would you please add more detailed description on what test you have
done?

e.g. Real platform? Unit Test? Etc.

-----Original Message-----
From: Christopher Zurcher <zurcher@...>
Sent: Thursday, September 22, 2022 4:26 AM
To: devel@edk2.groups.io
Cc: Li, Yi1 <yi1.li@...>; Yao, Jiewen <jiewen.yao@...>;
Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: [PATCH v1 0/3] CryptoPkg/OpensslLib: Add native instruction
support for IA32

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3654
PR: https://github.com/tianocore/edk2/pull/3352

This patch adds support for building the native instruction algorithms
for the IA32 architecture in OpensslLib. The base variant has been
tested with VS2019 and CLANGPDB toolchains, and a GCC variant is also
provided.

The implementation here follows the previous implementation of X64
native instructions as committed in 878a92a887.

Cc: Yi Li <yi1.li@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>

Christopher Zurcher (3):
CryptoPkg/OpensslLib: Add native instruction support for IA32
CryptoPkg/OpensslLib: Commit the auto-generated assembly files for
IA32
CryptoPkg/OpensslLib: Update generated files for native X64

CryptoPkg/CryptoPkg.ci.yaml | 4 +
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/aesni-x86.nasm | 3212
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/vpaes-x86.nasm | 651
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/modes/ghash-x86.nasm |
700
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha1-586.nasm | 1394
++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha256-586.nasm |
3364
++++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha512-586.nasm |
579
++++
CryptoPkg/Library/OpensslLib/IA32/crypto/x86cpuid.nasm | 433
+++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/aesni-x86.S | 3247
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/vpaes-x86.S | 670
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/modes/ghash-x86.S |
703
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha1-586.S | 1389
++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha256-586.S |
3356
+++++++++++++++++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha512-586.S | 574
++++
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/x86cpuid.S | 449
+++
CryptoPkg/Library/OpensslLib/OpensslLibIa32.inf | 699 ++++
CryptoPkg/Library/OpensslLib/OpensslLibIa32Gcc.inf | 699 ++++
CryptoPkg/Library/OpensslLib/OpensslLibX64.inf | 53 +
CryptoPkg/Library/OpensslLib/OpensslLibX64Gcc.inf | 53 +
CryptoPkg/Library/OpensslLib/UefiAsm.conf | 18 +
CryptoPkg/Library/OpensslLib/process_files.pl | 12 +
21 files changed, 22259 insertions(+) create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/aesni-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/aes/vpaes-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/modes/ghash-x86.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha1-
586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha256-586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/sha/sha512-586.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32/crypto/x86cpuid.nasm
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/aesni-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/aes/vpaes-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/modes/ghash-x86.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha1-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha256-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/sha/sha512-586.S
create mode 100644
CryptoPkg/Library/OpensslLib/IA32Gcc/crypto/x86cpuid.S
create mode 100644 CryptoPkg/Library/OpensslLib/OpensslLibIa32.inf
create mode 100644
CryptoPkg/Library/OpensslLib/OpensslLibIa32Gcc.inf

--
2.29.2.windows.2









Re: [edk2-platforms][PATCH v2 0/2] Update SbsaQemu/OemMiscLib

Ard Biesheuvel
 

On Fri, 23 Sept 2022 at 12:19, Sami Mujawar <sami.mujawar@...> wrote:

Hi Ard, Leif,

This patch series and the corresponding edk2 series at
https://edk2.groups.io/g/devel/message/93926 looks good to me and I have
tested these with SbsaQemu as well.

I already have a pull request for the edk2 series at
https://github.com/tianocore/edk2/pull/3391 and am planning to merge it
soon.

Can you let me know if I can merge this edk2-platform series as well,
please?
Yes, please go ahead whenever you feel is appropriate.

Thanks,
Ard.


On 19/09/2022 03:19 am, Nhi Pham wrote:
This patchset is to update SbsaQemu/OemMiscLib to reflect the recent
changes in edk2/OemMiscLib.

Changes since v1:
+ Update OemGetBiosRelease and
OemGetEmbeddedControllerFirmwareRelease functions [Leif, Sami]

Nhi Pham (2):
SbsaQemu/OemMiscLib: Update for new OemMiscLib APIs
SbsaQemu/OemMiscLib: Fix typo of "AssetTagType02"

Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 5 +++
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 44 +++++++++++++++++++-
2 files changed, 48 insertions(+), 1 deletion(-)




Re: [edk2-platforms][PATCH v2 0/2] Update SbsaQemu/OemMiscLib

Sami Mujawar
 

Hi Ard, Leif,

This patch series and the corresponding edk2 series at https://edk2.groups.io/g/devel/message/93926 looks good to me and I have tested these with SbsaQemu as well.

I already have a pull request for the edk2 series at https://github.com/tianocore/edk2/pull/3391 and am planning to merge it soon.

Can you let me know if I can merge this edk2-platform series as well, please?

Regards,

Sami Mujawar

On 19/09/2022 03:19 am, Nhi Pham wrote:
This patchset is to update SbsaQemu/OemMiscLib to reflect the recent
changes in edk2/OemMiscLib.

Changes since v1:
+ Update OemGetBiosRelease and
OemGetEmbeddedControllerFirmwareRelease functions [Leif, Sami]

Nhi Pham (2):
SbsaQemu/OemMiscLib: Update for new OemMiscLib APIs
SbsaQemu/OemMiscLib: Fix typo of "AssetTagType02"

Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 5 +++
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 44 +++++++++++++++++++-
2 files changed, 48 insertions(+), 1 deletion(-)


Re: [PATCH V3 0/3] CryptoPkg: Add BigNum support

Yao, Jiewen
 

Reviewed-by: Jiewen Yao <Jiewen.yao@...>

Merged https://github.com/tianocore/edk2/pull/3390

-----Original Message-----
From: Li, Yi1 <yi1.li@...>
Sent: Wednesday, September 21, 2022 1:28 PM
To: devel@edk2.groups.io
Cc: Li, Yi1 <yi1.li@...>; Yao, Jiewen <jiewen.yao@...>; Wang,
Jian J <jian.j.wang@...>; Lu, Xiaoyu1 <xiaoyu1.lu@...>; Jiang,
Guomin <guomin.jiang@...>
Subject: [PATCH V3 0/3] CryptoPkg: Add BigNum support

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

Review PR: https://github.com/tianocore/edk2/pull/3309
This patch sequence is used to add CryptBn library, which are wrapped
over OpenSSL. The implementation provides library functions for EFI
BaseCrypt protocol and EFI BaseCrypt Configuration Protocol.

All APIs passed unit test and fuzzing test, detail as:
1. Unit test:
The purpose of unit testing is to ensure that the function obtains the
expected result under specific input, that is, to ensure the correctness
of APIs.
All test case show in patch 3 :CryptoPkg/Test: Add unit test for CryptoBn.
2. Fuzzing test:
Various Fuzz Testing are employed across the all introduced APIs, and the
test is used AFL (2.52b) and Libfuzzer (clang+llvm-11.0.0) as the fuzzer,
based on HBFA.
Fuzzing Pass Rate is 100%;
The Code Coverage new APIs is 100%;
All test case show in:
https://github.com/liyi77/edk2-
staging/tree/HBFA/HBFA/UefiHostFuzzTestCasePkg/TestCase/CryptoPkg

V2 change:
1. Squash uncrustify tool update into previous patch.
2. Increase EDKII_CRYPTO_VERSION to 9.

Tested-by: Yi Li <yi1.li@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>

Signed-off-by: Yi Li <yi1.li@...>

Yi Li (3):
CryptoPkg: Add BigNum support
CryptoPkg: Add BigNum API to DXE and protocol
CryptoPkg/Test: Add unit test for CryptoBn

CryptoPkg/CryptoPkg.dsc | 1 +
CryptoPkg/Driver/Crypto.c | 520 +++++++++++++++-
CryptoPkg/Include/Library/BaseCryptLib.h | 418 +++++++++++++
.../Pcd/PcdCryptoServiceFamilyEnable.h | 30 +
.../Library/BaseCryptLib/BaseCryptLib.inf | 1 +
CryptoPkg/Library/BaseCryptLib/Bn/CryptBn.c | 581
++++++++++++++++++
.../Library/BaseCryptLib/Bn/CryptBnNull.c | 520 ++++++++++++++++
.../Library/BaseCryptLib/PeiCryptLib.inf | 1 +
.../Library/BaseCryptLib/SmmCryptLib.inf | 1 +
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 1 +
.../BaseCryptLibNull/BaseCryptLibNull.inf | 1 +
.../Library/BaseCryptLibNull/Bn/CryptBnNull.c | 520 ++++++++++++++++
.../BaseCryptLibOnProtocolPpi/CryptLib.c | 492 +++++++++++++++
CryptoPkg/Private/Protocol/Crypto.h | 429 ++++++++++++-
.../BaseCryptLib/BaseCryptLibUnitTests.c | 1 +
.../UnitTest/Library/BaseCryptLib/BnTests.c | 266 ++++++++
.../Library/BaseCryptLib/TestBaseCryptLib.h | 3 +
.../BaseCryptLib/TestBaseCryptLibHost.inf | 1 +
.../BaseCryptLib/TestBaseCryptLibShell.inf | 1 +
19 files changed, 3786 insertions(+), 2 deletions(-)
create mode 100644 CryptoPkg/Library/BaseCryptLib/Bn/CryptBn.c
create mode 100644 CryptoPkg/Library/BaseCryptLib/Bn/CryptBnNull.c
create mode 100644
CryptoPkg/Library/BaseCryptLibNull/Bn/CryptBnNull.c
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/BnTests.c

--
2.31.1.windows.1


Re: measurement to command-line/initrd for loading kernel via -kernel option

Ilias Apalodimas
 

Hi all,

Sorry for being late to the party. Ard cc'ed me in a prior mail, but that
got lost along the way

On Wed, Sep 21, 2022 at 05:41:14PM +0200, Ard Biesheuvel wrote:
On Wed, 21 Sept 2022 at 14:27, Gerd Hoffmann <kraxel@...> wrote:

On Wed, Sep 21, 2022 at 11:24:11AM +0000, Lu, Ken wrote:

But either in GenericQemuLoadImageLib, it can do measurement for
command line and initrd, correct?

Yes, it could. But why given that the linux kernel efi stub measures anyway?
If the final decision is the measurement should be done by efi stub in
Linux kernel.
The reference should be the workflow when you boot linux from efi shell
or using a BootNNNN entry. Which I think is:

(1) linux kernel is loaded + measured via Loadimage().
(2) linux kernel is started via efi stub entry point.
(3) linux kernel efi stub loads and measures the initrd.

Not fully sure about the command line measurement, IIRC Ard described
that in one of the replies.
If the image was booted from a BootNNNN entry, the entire variable
will be measured into the TPM, including the load options aka command
line.

If you use the shell or another loader that has no explicit awareness
of secure boot or measured boot, the load options are not measured at
all.
As others mentioned before me, I think the proposal here is reasonable.
Yes the TCG spec tries to avoid measuring things twice, but the reality is
that if we do so we'll probably end up with binaries or config options not
being measured depending on how the OS booted. On top of that the efi-stub
measures the contents of the initramfs and the LoadOptions in PCR9, which
is meant to be used by the OS. That should give enough freedom to people
when deciding which PCRs to use on sealing etc.

Do we also need remove today's measurement in Grub (I
have submitted some patch for TDX in grub...)?
Those patches are perfectly fine, tpm measurement and tdx measurement
should be consistent. In case the grub measurement workflow needs
changes to avoid double measurements (not sure this is actually the
case) those changes should apply to both tpm and tdx.
Agreed. I think the decision what to measure and what not to measure
is orthogonal to the type of measured boot that is being used.
I'd like to take the opportunity here and explain what happens on the
efi-stub measurements. GRUB uses the EV_IPL type for the eventlog.
This event was marked as deprecated in older versions of the spec. However
on the latest versions that changed and it now says:

- "May be used by Boot Manager Code to measure events. The contents of the
event field are specified by the caller."

Since it mentions "boot manager" and the efi-stub is an OS loader,
we used EV_EVENT_TAG for the initrd contents and the LoadOptions. The
description for that type is:

- "Used for PCRs defined for OS and application usage. Defined for use by
Host Platform Operating System or Software", which is a closer match.
On top of that the opaque EV_EVENT_TAG event is a bit cleaner and allows
us to mark events using its u32 tagged EventID and it easily extended for
any future measurements we want to add.

However when I re-read the event description there's a confusing sentence
on it's description saying "The digests field MUST contain the tagged
hash of the event data for each bank.". This contradicts the
TCG_PCR_EVENT2 Structure description for the digests field, as it allows
you to measure either the event data or external data. It also means that
when measuring the initrd we'll end up with an > 80mb event data, which is silly.

Anyone knows if that's a typo on the spec? Or as we abusing EV_EVENT_TAG?

Thanks
/Ilias


According to Bottomley, the same measurement should not be done twice.
Yes, this is the way it should be, although the current state of affairs
is a bit messy and I think we are a bit away from that ideal.

Or only the one who use GenericQemuLoadImageLib, will give the Linux
kernel efi stub for measure?
I think we don't have to do anything special in GenericQemuLoadImageLib
because the lib uses Loadimage() which should handle measurement.




Re: [PATCH V2 0/4] CryptoPkg: add AeadAesGcm support.

Yao, Jiewen
 

-----Original Message-----
From: Zhang, Qi1 <qi1.zhang@...>
Sent: Friday, September 23, 2022 2:32 PM
To: devel@edk2.groups.io
Cc: Zhang, Qi1 <qi1.zhang@...>; Yao, Jiewen
<jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: [PATCH V2 0/4] CryptoPkg: add AeadAesGcm support.

Add AeadAesGcm Encrypt and Decrypt.
With this change, the size increase of BaseCyrptLib is about 60K bytes.
The new functions are verifed by the Host UnitTest.
And also it has been integratd in
https://github.com/tianocore/edk2-staging/tree/DeviceSecurity and been
verified.

All the code change is on the PR
https://github.com/tianocore/edk2/pull/3224.


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

Signed-off-by: Qi Zhang <qi1.zhang@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Reviewed-by: Jiewen Yao <jiewen.yao@...>

Qi Zhang (4):
CryptoPkg: add AeadAesGcm function() definition.
CryptoPkg: add AeadAesGcm support.
CryptoPkg: add AeadAesGcm to Crypto Service.
CryptoPkg: add UnitTest for AeadAesGcm.

CryptoPkg/CryptoPkg.dsc | 2 +
CryptoPkg/Driver/Crypto.c | 94 +++++-
CryptoPkg/Include/Library/BaseCryptLib.h | 87 ++++++
.../Pcd/PcdCryptoServiceFamilyEnable.h | 7 +
.../Library/BaseCryptLib/BaseCryptLib.inf | 1 +
.../BaseCryptLib/Cipher/CryptAeadAesGcm.c | 279
++++++++++++++++++
.../BaseCryptLib/Cipher/CryptAeadAesGcmNull.c | 100 +++++++
.../Library/BaseCryptLib/PeiCryptLib.inf | 1 +
.../Library/BaseCryptLib/RuntimeCryptLib.inf | 1 +
.../Library/BaseCryptLib/SmmCryptLib.inf | 1 +
.../BaseCryptLib/UnitTestHostBaseCryptLib.inf | 1 +
.../BaseCryptLibNull/BaseCryptLibNull.inf | 1 +
.../Cipher/CryptAeadAesGcmNull.c | 100 +++++++
.../BaseCryptLibOnProtocolPpi/CryptLib.c | 93 ++++++
CryptoPkg/Private/Protocol/Crypto.h | 88 +++++-
.../Library/BaseCryptLib/AeadAesGcmTests.c | 112 +++++++
.../BaseCryptLib/BaseCryptLibUnitTests.c | 1 +
.../Library/BaseCryptLib/TestBaseCryptLib.h | 3 +
.../BaseCryptLib/TestBaseCryptLibHost.inf | 1 +
.../BaseCryptLib/TestBaseCryptLibShell.inf | 1 +
20 files changed, 972 insertions(+), 2 deletions(-)
create mode 100644
CryptoPkg/Library/BaseCryptLib/Cipher/CryptAeadAesGcm.c
create mode 100644
CryptoPkg/Library/BaseCryptLib/Cipher/CryptAeadAesGcmNull.c
create mode 100644
CryptoPkg/Library/BaseCryptLibNull/Cipher/CryptAeadAesGcmNull.c
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/AeadAesGcmTests.c

--
2.26.2.windows.1


Re: [PATCH] MdeModulePkg/TerminalDxe: add modes

Gerd Hoffmann
 

On Thu, Sep 22, 2022 at 07:49:39PM +0300, Konstantin Aladyshev wrote:
Yes, I use QEMU to run OVMF in Linux (actually in WSL). Here is a
command that I use for launch:
```
qemu-system-x86_64 \
-drive if=pflash,format=raw,file=Build/OvmfX64/RELEASE_GCC5/FV/OVMF.fd \
-drive format=raw,file=fat:rw:~/UEFI_disk
-vnc :1
```
So nothing explicit about the UARTs.
qemu adds a bunch of default devices for convenience.
vga, nic, cdrom, serial port.

You can use '-nodefaults' to turn off all of them or '-serial none'
to turn off the serial port only.

take care,
Gerd


Re: [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

Wu, Hao A
 

Hello,

 

As I mentioned previously, if the code execution flow is:

UsbEnumeratePort

    Status = HubApi->GetPortStatus (HubIf, Port, &PortState);

        UsbRootHubGetPortStatus

            UsbHcGetRootHubPortStatus

                XhcGetRootHubPortStatus

Then the content in PortState will be initialized to 0 within XhcGetRootHubPortStatus().

 

I think you need to double confirm what is the exact code execution flow in your case and justify why the first patch is needed to resolve the issue you met.

Could you help on this? Based on the current information I got during the discussion, I have no idea on why the proposed change can resolve the issue.

 

Best Regards,

Hao Wu

 

From: Sean Rhodes <sean@...>
Sent: Friday, September 23, 2022 4:02 PM
To: Wu, Hao A <hao.a.wu@...>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

 

Hi Hao

 

I retested, and it seems you are correct; the second patch has no effect. Still, the first is required to resolve the issue - https://github.com/tianocore/edk2/pull/3353

 

Maybe it is because enumeration happens with the port status not zero'd?

 

Thanks

 

Sean

 

On Thu, 22 Sept 2022 at 08:30, Wu, Hao A <hao.a.wu@...> wrote:

Hello,

 

1. For “"Avoid continuing on error path" - The reset can happen before PortState is zero'd, so running this at the start of the function ensures it will”:

My take is that the execution flow is like:

UsbEnumeratePort

    Status = HubApi->GetPortStatus (HubIf, Port, &PortState);

        UsbRootHubGetPortStatus

            UsbHcGetRootHubPortStatus

                XhcGetRootHubPortStatus

If this is the case, within XhcGetRootHubPortStatus (MdeModulePkg\Bus\Pci\XhciDxe\Xhci.c), it does have logic to:

  Offset                       = (UINT32)(XHC_PORTSC_OFFSET + (0x10 * PortNumber));

  PortStatus->PortStatus       = 0;

  PortStatus->PortChangeStatus = 0;

I am not sure why the below proposed change in UsbEnumeratePort can resolve the issue:

  // Zero out PortState in case GetPortStatus does not set it and we

  // continue on the EFI_DEVICE_ERROR path

  PortState.PortStatus       = 0;

  PortState.PortChangeStatus = 0;

 

Or the test you are performing includes connecting USB devices on a USB Hub?

 

2. For “" Reset the device on error" - this will only attempt enumeration if there isn't an error.”:

As I mentioned in reply of that patch, by the code execution reaches the change you made:
    if (USB_BIT_IS_SET (PortState.PortChangeStatus, USB_PORT_STAT_C_RESET) &&

        (Status != EFI_DEVICE_ERROR))

‘Status’ will always be EFI_SUCCESS, I do not understand what is the point of adding “&& (Status != EFI_DEVICE_ERROR)”.

Could you help to double check if the change is really what you want to do?

 

Best Regards,

Hao Wu

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean Rhodes
Sent: Wednesday, September 21, 2022 4:37 PM
To: Wu, Hao A <hao.a.wu@...>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

 

Hi Hao

 

If I just boot a device to the EFI shell and then connect a USB, edk2 will constantly try to access the device, fail and reset the port. It won't stop doing this, and the USB drive can't be accessed.

 

I tested 13 USB drives; 8 saw this problem, and 5 worked correctly. It doesn't matter which SOC, or if the port is USB 2.0 or 3.0.

 

" Reset the device on error" - this will only attempt enumeration if there isn't an error.

"Avoid continuing on error path" - The reset can happen before PortState is zero'd, so running this at the start of the function ensures it will

 

Hopefully, that makes sense!

 

Thanks


Sean

 

 

On Wed, 21 Sept 2022 at 09:24, Wu, Hao A <hao.a.wu@...> wrote:

Sorry, could you help to explain more on the endless loop? Like what causes the loop and why the proposed change can resolve the issue.

I am not experienced enough in the USB domain to quickly figure out the whole picture with only log being provided.

 

Best Regards,

Hao Wu

 

From: Sean Rhodes <sean@...>
Sent: Wednesday, September 21, 2022 4:01 PM
To: Wu, Hao A <hao.a.wu@...>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

 

Hi Hao

 

I've attached a debug log for the problem I'm trying to solve (these two patches solve it).

 

The reset happens before PortState changes, so it's an endless loop.

 

Thanks

 

Sean

 

On Wed, 21 Sept 2022 at 06:31, Wu, Hao A <hao.a.wu@...> wrote:

Sorry, could you help to share more information on what issue is met for this proposed patch?

It seems to me that the change made below is to handle the case where:

  Status = HubApi->GetPortStatus (HubIf, Port, &PortState);

  if (EFI_ERROR (Status)) {
    DEBUG ((DEBUG_ERROR, "UsbEnumeratePort: failed to get state of port %d\n", Port));
    return Status;
  }

GetPortStatus() returns EFI_ SUCCESS, but does not update the output parameter 'PortState'.
Could you help to check what causes 'PortState' not being updated after a success return from GetPortStatus()? Thanks in advance.

Also, one inline comment below:


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Rhodes
> Sent: Tuesday, September 20, 2022 9:14 PM
> To: devel@edk2.groups.io
> Cc: Rhodes, Sean <sean@...>; Wu, Hao A
> <hao.a.wu@...>; Ni, Ray <ray.ni@...>
> Subject: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid
> continuing on error path
>
> Zero out the PortState in case GetPortStatus didn't set it, to avoid
> continuing with EFI_DEVICE_ERROR.
>
> Cc: Hao A Wu <hao.a.wu@...>
> Cc: Ray Ni <ray.ni@...>
> Signed-off-by: Sean Rhodes <sean@...>
> ---
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index aed34596f4..7fc567898a 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -900,6 +900,11 @@ UsbEnumeratePort (
>    Child  = NULL;
>
>    HubApi = HubIf->HubApi;
>
>
>
> +  // Zero out PortState in case GetPortStatus does not set it and we
>
> +  // continue on the EFI_DEVICE_ERROR path
>
> +  PortState.PortStatus       = 0;
>
> +  PortState.PortChangeStatus = 0;


Could you help to use:

  ZeroMem (&PortState, sizeof (EFI_USB_PORT_STATUS));

here to align with other places in this driver?


Best Regards,
Hao Wu


>
> +
>
>    //
>
>    // Host learns of the new device by polling the hub for port changes.
>
>    //
>
> --
> 2.34.1
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#93989): https://edk2.groups.io/g/devel/message/93989
> Mute This Topic: https://groups.io/mt/93802896/1768737
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [hao.a.wu@...]
> -=-=-=-=-=-=
>


Re: [PATCH v1 05/34] NetworkPkg: Add LOONGARCH64 architecture for EDK2 CI.

Wu, Jiaxin
 

Reviewed-by: Jiaxin Wu <jiaxin.wu@...>

-----Original Message-----
From: Chao Li <lichao@...>
Sent: Thursday, September 8, 2022 12:48 PM
To: devel@edk2.groups.io
Cc: Maciej Rabeda <maciej.rabeda@...>; Wu, Jiaxin
<jiaxin.wu@...>; Siyuan Fu <siyuan.fu@...>
Subject: [PATCH v1 05/34] NetworkPkg: Add LOONGARCH64 architecture for
EDK2 CI.

Add LOONGARCH64 architecture for EDK2 CI testing.

Cc: Maciej Rabeda <maciej.rabeda@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Siyuan Fu <siyuan.fu@...>

Signed-off-by: Chao Li <lichao@...>
---
NetworkPkg/NetworkPkg.dsc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/NetworkPkg.dsc b/NetworkPkg/NetworkPkg.dsc
index 762134023d..6c231c97b5 100644
--- a/NetworkPkg/NetworkPkg.dsc
+++ b/NetworkPkg/NetworkPkg.dsc
@@ -4,6 +4,7 @@
# (C) Copyright 2014 Hewlett-Packard Development Company, L.P.<BR>

# Copyright (c) 2009 - 2021, Intel Corporation. All rights reserved.<BR>

# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
reserved.<BR>

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights
reserved.<BR>

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

##

@@ -14,7 +15,7 @@
PLATFORM_VERSION = 0.98

DSC_SPECIFICATION = 0x00010005

OUTPUT_DIRECTORY = Build/NetworkPkg

- SUPPORTED_ARCHITECTURES =
IA32|X64|EBC|ARM|AARCH64|RISCV64

+ SUPPORTED_ARCHITECTURES =
IA32|X64|EBC|ARM|AARCH64|RISCV64|LOONGARCH64

BUILD_TARGETS = DEBUG|RELEASE|NOOPT

SKUID_IDENTIFIER = DEFAULT



--
2.27.0


Re: [PATCH v2 06/34] NetworkPkg/HttpBootDxe: Add LOONGARCH64 architecture for EDK2 CI.

Wu, Jiaxin
 

Reviewed-by: Jiaxin Wu <jiaxin.wu@...>

-----Original Message-----
From: Chao Li <lichao@...>
Sent: Wednesday, September 14, 2022 5:36 PM
To: devel@edk2.groups.io
Cc: Maciej Rabeda <maciej.rabeda@...>; Wu, Jiaxin
<jiaxin.wu@...>; Siyuan Fu <siyuan.fu@...>
Subject: [PATCH v2 06/34] NetworkPkg/HttpBootDxe: Add LOONGARCH64
architecture for EDK2 CI.

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

Add LOONGARCH architecture for EDK2 CI testing.

Cc: Maciej Rabeda <maciej.rabeda@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Siyuan Fu <siyuan.fu@...>

Signed-off-by: Chao Li <lichao@...>
---
NetworkPkg/HttpBootDxe/HttpBootDhcp4.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp4.h
b/NetworkPkg/HttpBootDxe/HttpBootDhcp4.h
index d76f0e84d6..f00fabead2 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDhcp4.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp4.h
@@ -3,6 +3,7 @@


Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.<BR>

Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
reserved.<BR>

+Copyright (c) 2022, Loongson Technology Corporation Limited. All rights
reserved.<BR>

SPDX-License-Identifier: BSD-2-Clause-Patent



**/

@@ -40,6 +41,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#define EFI_HTTP_BOOT_CLIENT_SYSTEM_ARCHITECTURE
HTTP_CLIENT_ARCH_RISCV64

#elif defined (MDE_CPU_EBC)

#define EFI_HTTP_BOOT_CLIENT_SYSTEM_ARCHITECTURE
HTTP_CLIENT_ARCH_EBC

+#elif defined (MDE_CPU_LOONGARCH64)

+#define EFI_HTTP_BOOT_CLIENT_SYSTEM_ARCHITECTURE
HTTP_CLIENT_ARCH_LOONGARCH64

#endif



/// DHCP offer types among HTTP boot.

--
2.27.0


Re: [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

Sean Rhodes
 

Hi Hao

I retested, and it seems you are correct; the second patch has no effect. Still, the first is required to resolve the issue - https://github.com/tianocore/edk2/pull/3353

Maybe it is because enumeration happens with the port status not zero'd?

Thanks

Sean

On Thu, 22 Sept 2022 at 08:30, Wu, Hao A <hao.a.wu@...> wrote:

Hello,

 

1. For “"Avoid continuing on error path" - The reset can happen before PortState is zero'd, so running this at the start of the function ensures it will”:

My take is that the execution flow is like:

UsbEnumeratePort

    Status = HubApi->GetPortStatus (HubIf, Port, &PortState);

        UsbRootHubGetPortStatus

            UsbHcGetRootHubPortStatus

                XhcGetRootHubPortStatus

If this is the case, within XhcGetRootHubPortStatus (MdeModulePkg\Bus\Pci\XhciDxe\Xhci.c), it does have logic to:

  Offset                       = (UINT32)(XHC_PORTSC_OFFSET + (0x10 * PortNumber));

  PortStatus->PortStatus       = 0;

  PortStatus->PortChangeStatus = 0;

I am not sure why the below proposed change in UsbEnumeratePort can resolve the issue:

  // Zero out PortState in case GetPortStatus does not set it and we

  // continue on the EFI_DEVICE_ERROR path

  PortState.PortStatus       = 0;

  PortState.PortChangeStatus = 0;

 

Or the test you are performing includes connecting USB devices on a USB Hub?

 

2. For “" Reset the device on error" - this will only attempt enumeration if there isn't an error.”:

As I mentioned in reply of that patch, by the code execution reaches the change you made:
    if (USB_BIT_IS_SET (PortState.PortChangeStatus, USB_PORT_STAT_C_RESET) &&

        (Status != EFI_DEVICE_ERROR))

‘Status’ will always be EFI_SUCCESS, I do not understand what is the point of adding “&& (Status != EFI_DEVICE_ERROR)”.

Could you help to double check if the change is really what you want to do?

 

Best Regards,

Hao Wu

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean Rhodes
Sent: Wednesday, September 21, 2022 4:37 PM
To: Wu, Hao A <hao.a.wu@...>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

 

Hi Hao

 

If I just boot a device to the EFI shell and then connect a USB, edk2 will constantly try to access the device, fail and reset the port. It won't stop doing this, and the USB drive can't be accessed.

 

I tested 13 USB drives; 8 saw this problem, and 5 worked correctly. It doesn't matter which SOC, or if the port is USB 2.0 or 3.0.

 

" Reset the device on error" - this will only attempt enumeration if there isn't an error.

"Avoid continuing on error path" - The reset can happen before PortState is zero'd, so running this at the start of the function ensures it will

 

Hopefully, that makes sense!

 

Thanks


Sean

 

 

On Wed, 21 Sept 2022 at 09:24, Wu, Hao A <hao.a.wu@...> wrote:

Sorry, could you help to explain more on the endless loop? Like what causes the loop and why the proposed change can resolve the issue.

I am not experienced enough in the USB domain to quickly figure out the whole picture with only log being provided.

 

Best Regards,

Hao Wu

 

From: Sean Rhodes <sean@...>
Sent: Wednesday, September 21, 2022 4:01 PM
To: Wu, Hao A <hao.a.wu@...>
Cc: devel@edk2.groups.io; Ni, Ray <ray.ni@...>
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid continuing on error path

 

Hi Hao

 

I've attached a debug log for the problem I'm trying to solve (these two patches solve it).

 

The reset happens before PortState changes, so it's an endless loop.

 

Thanks

 

Sean

 

On Wed, 21 Sept 2022 at 06:31, Wu, Hao A <hao.a.wu@...> wrote:

Sorry, could you help to share more information on what issue is met for this proposed patch?

It seems to me that the change made below is to handle the case where:

  Status = HubApi->GetPortStatus (HubIf, Port, &PortState);

  if (EFI_ERROR (Status)) {
    DEBUG ((DEBUG_ERROR, "UsbEnumeratePort: failed to get state of port %d\n", Port));
    return Status;
  }

GetPortStatus() returns EFI_ SUCCESS, but does not update the output parameter 'PortState'.
Could you help to check what causes 'PortState' not being updated after a success return from GetPortStatus()? Thanks in advance.

Also, one inline comment below:


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Rhodes
> Sent: Tuesday, September 20, 2022 9:14 PM
> To: devel@edk2.groups.io
> Cc: Rhodes, Sean <sean@...>; Wu, Hao A
> <hao.a.wu@...>; Ni, Ray <ray.ni@...>
> Subject: [edk2-devel] [PATCH 1/2] MdeModulePkg/UsbBusDxe: Avoid
> continuing on error path
>
> Zero out the PortState in case GetPortStatus didn't set it, to avoid
> continuing with EFI_DEVICE_ERROR.
>
> Cc: Hao A Wu <hao.a.wu@...>
> Cc: Ray Ni <ray.ni@...>
> Signed-off-by: Sean Rhodes <sean@...>
> ---
>  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> index aed34596f4..7fc567898a 100644
> --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
> @@ -900,6 +900,11 @@ UsbEnumeratePort (
>    Child  = NULL;
>
>    HubApi = HubIf->HubApi;
>
>
>
> +  // Zero out PortState in case GetPortStatus does not set it and we
>
> +  // continue on the EFI_DEVICE_ERROR path
>
> +  PortState.PortStatus       = 0;
>
> +  PortState.PortChangeStatus = 0;


Could you help to use:

  ZeroMem (&PortState, sizeof (EFI_USB_PORT_STATUS));

here to align with other places in this driver?


Best Regards,
Hao Wu


>
> +
>
>    //
>
>    // Host learns of the new device by polling the hub for port changes.
>
>    //
>
> --
> 2.34.1
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#93989): https://edk2.groups.io/g/devel/message/93989
> Mute This Topic: https://groups.io/mt/93802896/1768737
> Group Owner: devel+owner@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [hao.a.wu@...]
> -=-=-=-=-=-=
>


Re: [PATCH V2 0/4] CryptoPkg: Add Hkdf SHA384 support

Yao, Jiewen
 

-----Original Message-----
From: Zhang, Qi1 <qi1.zhang@...>
Sent: Friday, September 23, 2022 2:25 PM
To: devel@edk2.groups.io
Cc: Zhang, Qi1 <qi1.zhang@...>; Yao, Jiewen
<jiewen.yao@...>; Wang, Jian J <jian.j.wang@...>; Lu, Xiaoyu1
<xiaoyu1.lu@...>; Jiang, Guomin <guomin.jiang@...>
Subject: [PATCH V2 0/4] CryptoPkg: Add Hkdf SHA384 support

Add Hkdf-SHA384 support and Hkdf-SHA256 extract and expand separately.
With this change, the size increase of BaseCyrptLib is about 6K bytes.
The new functions are verifed by the Host UnitTest.
And also it has been integratd in
https://github.com/tianocore/edk2-staging/tree/DeviceSecurity and been
verified.

All the code change is on the PR
https://github.com/tianocore/edk2/pull/3224.

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

Signed-off-by: Qi Zhang <qi1.zhang@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Xiaoyu Lu <xiaoyu1.lu@...>
Cc: Guomin Jiang <guomin.jiang@...>
Reviewed-by: Jiewen Yao <jiewen.yao@...>

Qi Zhang (4):
CryptoPkg: add new Hkdf api definition in Crypt Lib.
CryptoPkg: add new Hkdf api in Crypt Lib.
CryptoPkg: add new Hkdf api to Crypto Service.
CryptoPkg: add Hkdf UnitTest.

CryptoPkg/Driver/Crypto.c | 152 +++++++-
CryptoPkg/Include/Library/BaseCryptLib.h | 129 +++++++
.../Pcd/PcdCryptoServiceFamilyEnable.h | 7 +-
.../Library/BaseCryptLib/Kdf/CryptHkdf.c | 362 +++++++++++++++++-
.../Library/BaseCryptLib/Kdf/CryptHkdfNull.c | 151 +++++++-
.../BaseCryptLibNull/Kdf/CryptHkdfNull.c | 151 +++++++-
.../BaseCryptLibOnProtocolPpi/CryptLib.c | 144 +++++++
CryptoPkg/Private/Protocol/Crypto.h | 139 ++++++-
.../BaseCryptLib/BaseCryptLibUnitTests.c | 29 +-
.../UnitTest/Library/BaseCryptLib/HkdfTests.c | 202 ++++++++++
.../Library/BaseCryptLib/TestBaseCryptLib.h | 3 +
.../BaseCryptLib/TestBaseCryptLibHost.inf | 1 +
.../BaseCryptLib/TestBaseCryptLibShell.inf | 1 +
13 files changed, 1440 insertions(+), 31 deletions(-)
create mode 100644
CryptoPkg/Test/UnitTest/Library/BaseCryptLib/HkdfTests.c

--
2.26.2.windows.1


Re: [PATCH v2 32/34] MdeModulePkg/DxeIplPeim : LoongArch DxeIPL implementation.

Chao Li
 

Hi Liming and Guomin,
This patch has not been reviewed, would you please review it?


Thanks,
Chao
--------

On 9月 14 2022, at 5:42 下午, Chao Li <lichao@...> wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053

Implement LoongArch DxeIPL instance.

Cc: Liming Gao <gaoliming@...>
Cc: Guomin Jiang <guomin.jiang@...>

Signed-off-by: Chao Li <lichao@...>
Co-authored-by: Baoqi Zhang <zhangbaoqi@...>
---
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 6 +-
.../Core/DxeIplPeim/LoongArch64/DxeLoadFunc.c | 63 +++++++++++++++++++
2 files changed, 68 insertions(+), 1 deletion(-)
create mode 100644 MdeModulePkg/Core/DxeIplPeim/LoongArch64/DxeLoadFunc.c

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 19b8a4c8ae..052ea0ec1a 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -8,6 +8,7 @@
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>

# Copyright (c) 2017, AMD Incorporated. All rights reserved.<BR>

# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -26,7 +27,7 @@
#

# The following information is for reference only and not required by the build tools.

#

-# VALID_ARCHITECTURES = IA32 X64 EBC (EBC is for build only) AARCH64 RISCV64

+# VALID_ARCHITECTURES = IA32 X64 EBC (EBC is for build only) AARCH64 RISCV64 LOONGARCH64

#



[Sources]

@@ -53,6 +54,9 @@
[Sources.RISCV64]

RiscV64/DxeLoadFunc.c



+[Sources.LOONGARCH64]

+ LoongArch64/DxeLoadFunc.c

+

[Packages]

MdePkg/MdePkg.dec

MdeModulePkg/MdeModulePkg.dec

diff --git a/MdeModulePkg/Core/DxeIplPeim/LoongArch64/DxeLoadFunc.c b/MdeModulePkg/Core/DxeIplPeim/LoongArch64/DxeLoadFunc.c
new file mode 100644
index 0000000000..95d3af19ea
--- /dev/null
+++ b/MdeModulePkg/Core/DxeIplPeim/LoongArch64/DxeLoadFunc.c
@@ -0,0 +1,63 @@
+/** @file

+ LoongArch specifc functionality for DxeLoad.

+

+ Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

+

+ SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include "DxeIpl.h"

+

+/**

+ Transfers control to DxeCore.

+

+ This function performs a CPU architecture specific operations to execute

+ the entry point of DxeCore with the parameters of HobList.

+ It also installs EFI_END_OF_PEI_PPI to signal the end of PEI phase.

+

+ @param[in] DxeCoreEntryPoint The entry point of DxeCore.

+ @param[in] HobList The start of HobList passed to DxeCore.

+

+**/

+VOID

+HandOffToDxeCore (

+ IN EFI_PHYSICAL_ADDRESS DxeCoreEntryPoint,

+ IN EFI_PEI_HOB_POINTERS HobList

+ )

+{

+ VOID *BaseOfStack;

+ VOID *TopOfStack;

+ EFI_STATUS Status;

+

+ //

+ // Allocate 128KB for the Stack

+ //

+ BaseOfStack = AllocatePages (EFI_SIZE_TO_PAGES (STACK_SIZE));

+ ASSERT (BaseOfStack != NULL);

+

+ //

+ // Compute the top of the stack we were allocated. Pre-allocate a UINTN

+ // for safety.

+ //

+ TopOfStack = (VOID *)((UINTN)BaseOfStack + EFI_SIZE_TO_PAGES (STACK_SIZE) * EFI_PAGE_SIZE - CPU_STACK_ALIGNMENT);

+ TopOfStack = ALIGN_POINTER (TopOfStack, CPU_STACK_ALIGNMENT);

+

+ //

+ // End of PEI phase signal

+ //

+ Status = PeiServicesInstallPpi (&gEndOfPeiSignalPpi);

+ ASSERT_EFI_ERROR (Status);

+

+ //

+ // Update the contents of BSP stack HOB to reflect the real stack info passed to DxeCore.

+ //

+ UpdateStackHob ((EFI_PHYSICAL_ADDRESS)(UINTN)BaseOfStack, STACK_SIZE);

+

+ SwitchStack (

+ (SWITCH_STACK_ENTRY_POINT)(UINTN)DxeCoreEntryPoint,

+ HobList.Raw,

+ NULL,

+ TopOfStack

+ );

+}

--
2.27.0


Re: [PATCH v2 29/34] MdePkg/BaseSafeIntLib: Add LoongArch64 architecture for BaseSafeIntLib.

Chao Li
 

Hi Mike, Liming and Zhiguang,
This patch has not been reviewed, would you please review it?


Thanks,
Chao
--------

On 9月 14 2022, at 5:41 下午, Chao Li <lichao@...> wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053

Add LoongArch64 architecture for BaseSafeIntLib library.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Chao Li <lichao@...>
---
MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf b/MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
index 40017ec88b..9d039f2e5b 100644
--- a/MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
+++ b/MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
@@ -4,9 +4,10 @@
# This library provides helper functions to prevent integer overflow during

# type conversion, addition, subtraction, and multiplication.

#

-# Copyright (c) 2018, Intel Corporation. All rights reserved.<BR>

+# Copyright (c) 2018, Intel Corporation. All rights reserved.<BR>

# Copyright (c) 2017, Microsoft Corporation

-# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>



#

# All rights reserved.

@@ -25,7 +26,7 @@
#

# The following information is for reference only and not required by the build tools.

#

-# VALID_ARCHITECTURES = IA32 X64 ARM AARCH64 RISCV64

+# VALID_ARCHITECTURES = IA32 X64 ARM AARCH64 RISCV64 LOONGARCH64

#



[Sources]

@@ -34,7 +35,7 @@
[Sources.Ia32, Sources.ARM]

SafeIntLib32.c



-[Sources.X64, Sources.AARCH64, Sources.RISCV64]

+[Sources.X64, Sources.AARCH64, Sources.RISCV64, Sources.LOONGARCH64]

SafeIntLib64.c



[Sources.EBC]

--
2.27.0


Re: [PATCH v2 28/34] MdePkg/BaseSynchronizationLib: LoongArch cache related code.

Chao Li
 

Hi Mike, Liming and Zhiguang,
This patch has not been reviewed, would you please review it?


Thanks,
Chao
--------

On 9月 14 2022, at 5:41 下午, Chao Li <lichao@...> wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053

Support LoongArch cache related functions.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Chao Li <lichao@...>
Co-authored-by: Baoqi Zhang <zhangbaoqi@...>
---
.../BaseSynchronizationLib.inf | 5 +
.../LoongArch64/Synchronization.c | 246 ++++++++++++++++++
2 files changed, 251 insertions(+)
create mode 100644 MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c

diff --git a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
index 02ba12961a..10021f3352 100755
--- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
@@ -4,6 +4,7 @@
# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.<BR>

# Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -82,6 +83,10 @@
Synchronization.c

RiscV64/Synchronization.S



+[Sources.LOONGARCH64]

+ Synchronization.c

+ LoongArch64/Synchronization.c

+

[Packages]

MdePkg/MdePkg.dec



diff --git a/MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c
new file mode 100644
index 0000000000..b7789f3212
--- /dev/null
+++ b/MdePkg/Library/BaseSynchronizationLib/LoongArch64/Synchronization.c
@@ -0,0 +1,246 @@
+/** @file

+ LoongArch synchronization functions.

+

+ Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

+

+ SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include <Library/DebugLib.h>

+

+/**

+ Performs an atomic compare exchange operation on a 16-bit

+ unsigned integer.

+

+ Performs an atomic compare exchange operation on the 16-bit

+ unsigned integer specified by Value. If Value is equal to

+ CompareValue, then Value is set to ExchangeValue and

+ CompareValue is returned. If Value is not equal to

+ CompareValue, then Value is returned. The compare exchange

+ operation must be performed using MP safe mechanisms.

+

+ @param[in] Value A pointer to the 16-bit value for the

+ compare exchange operation.

+ @param[in] CompareValue 16-bit value used in compare operation.

+ @param[in] ExchangeValue 16-bit value used in exchange operation.

+

+ @return The original *Value before exchange.

+

+**/

+UINT16

+EFIAPI

+InternalSyncCompareExchange16 (

+ IN volatile UINT16 *Value,

+ IN UINT16 CompareValue,

+ IN UINT16 ExchangeValue

+ )

+{

+ UINT32 RetValue;

+ UINT32 Temp;

+ UINT32 Shift;

+ UINT64 Mask;

+ UINT64 LocalCompareValue;

+ UINT64 LocalExchangeValue;

+ volatile UINT32 *Ptr32;

+

+ /* Check that ptr is naturally aligned */

+ ASSERT (!((UINT64)Value & (sizeof (Value) - 1)));

+

+ /* Mask inputs to the correct size. */

+ Mask = (((~0UL) - (1UL << (0)) + 1) & (~0UL >> (64 - 1 - ((sizeof (UINT16) * 8) - 1))));

+ LocalCompareValue = ((UINT64)CompareValue) & Mask;

+ LocalExchangeValue = ((UINT64)ExchangeValue) & Mask;

+

+ /*

+ * Calculate a shift & mask that correspond to the value we wish to

+ * compare & exchange within the naturally aligned 4 byte integer

+ * that includes it.

+ */

+ Shift = (UINT64)Value & 0x3;

+ Shift *= 8; /* BITS_PER_BYTE */

+ LocalCompareValue <<= Shift;

+ LocalExchangeValue <<= Shift;

+ Mask <<= Shift;

+

+ /*

+ * Calculate a pointer to the naturally aligned 4 byte integer that

+ * includes our byte of interest, and load its value.

+ */

+ Ptr32 = (UINT32 *)((UINT64)Value & ~0x3);

+

+ __asm__ __volatile__ (

+ "1: \n"

+ "ll.w %0, %3 \n"

+ "and %1, %0, %4 \n"

+ "bne %1, %5, 2f \n"

+ "andn %1, %0, %4 \n"

+ "or %1, %1, %6 \n"

+ "sc.w %1, %2 \n"

+ "beqz %1, 1b \n"

+ "b 3f \n"

+ "2: \n"

+ "dbar 0 \n"

+ "3: \n"

+ : "=&r" (RetValue), "=&r" (Temp), "=" "ZC" (*Ptr32)

+ : "ZC" (*Ptr32), "Jr" (Mask), "Jr" (LocalCompareValue), "Jr" (LocalExchangeValue)

+ : "memory"

+ );

+

+ return (RetValue & Mask) >> Shift;

+}

+

+/**

+ Performs an atomic compare exchange operation on a 32-bit

+ unsigned integer.

+

+ Performs an atomic compare exchange operation on the 32-bit

+ unsigned integer specified by Value. If Value is equal to

+ CompareValue, then Value is set to ExchangeValue and

+ CompareValue is returned. If Value is not equal to

+ CompareValue, then Value is returned. The compare exchange

+ operation must be performed using MP safe mechanisms.

+

+ @param[in] Value A pointer to the 32-bit value for the

+ compare exchange operation.

+ @param[in] CompareValue 32-bit value used in compare operation.

+ @param[in] ExchangeValue 32-bit value used in exchange operation.

+

+ @return The original *Value before exchange.

+

+**/

+UINT32

+EFIAPI

+InternalSyncCompareExchange32 (

+ IN volatile UINT32 *Value,

+ IN UINT32 CompareValue,

+ IN UINT32 ExchangeValue

+ )

+{

+ UINT32 RetValue;

+

+ __asm__ __volatile__ (

+ "1: \n"

+ "ll.w %0, %2 \n"

+ "bne %0, %3, 2f \n"

+ "move %0, %4 \n"

+ "sc.w %0, %1 \n"

+ "beqz %0, 1b \n"

+ "b 3f \n"

+ "2: \n"

+ "dbar 0 \n"

+ "3: \n"

+ : "=&r" (RetValue), "=" "ZC" (*Value)

+ : "ZC" (*Value), "Jr" (CompareValue), "Jr" (ExchangeValue)

+ : "memory"

+ );

+ return RetValue;

+}

+

+/**

+ Performs an atomic compare exchange operation on a 64-bit unsigned integer.

+

+ Performs an atomic compare exchange operation on the 64-bit unsigned integer specified

+ by Value. If Value is equal to CompareValue, then Value is set to ExchangeValue and

+ CompareValue is returned. If Value is not equal to CompareValue, then Value is returned.

+ The compare exchange operation must be performed using MP safe mechanisms.

+

+ @param[in] Value A pointer to the 64-bit value for the compare exchange

+ operation.

+ @param[in] CompareValue 64-bit value used in compare operation.

+ @param[in] ExchangeValue 64-bit value used in exchange operation.

+

+ @return The original *Value before exchange.

+

+**/

+UINT64

+EFIAPI

+InternalSyncCompareExchange64 (

+ IN volatile UINT64 *Value,

+ IN UINT64 CompareValue,

+ IN UINT64 ExchangeValue

+ )

+{

+ UINT64 RetValue;

+

+ __asm__ __volatile__ (

+ "1: \n"

+ "ll.d %0, %2 \n"

+ "bne %0, %3, 2f \n"

+ "move %0, %4 \n"

+ "sc.d %0, %1 \n"

+ "beqz %0, 1b \n"

+ "b 3f \n"

+ "2: \n"

+ "dbar 0 \n"

+ "3: \n"

+ : "=&r" (RetValue), "=" "ZC" (*Value)

+ : "ZC" (*Value), "Jr" (CompareValue), "Jr" (ExchangeValue)

+ : "memory"

+ );

+ return RetValue;

+}

+

+/**

+ Performs an atomic increment of an 32-bit unsigned integer.

+

+ Performs an atomic increment of the 32-bit unsigned integer specified by

+ Value and returns the incremented value. The increment operation must be

+ performed using MP safe mechanisms. The state of the return value is not

+ guaranteed to be MP safe.

+

+ @param[in] Value A pointer to the 32-bit value to increment.

+

+ @return The incremented value.

+

+**/

+UINT32

+EFIAPI

+InternalSyncIncrement (

+ IN volatile UINT32 *Value

+ )

+{

+ UINT32 Temp;

+

+ Temp = *Value;

+ __asm__ __volatile__ (

+ "dbar 0 \n"

+ "amadd.w %1, %2, %0 \n"

+ : "+ZB" (*Value), "=&r" (Temp)

+ : "r" (1)

+ : "memory"

+ );

+ return *Value;

+}

+

+/**

+ Performs an atomic decrement of an 32-bit unsigned integer.

+

+ Performs an atomic decrement of the 32-bit unsigned integer specified by

+ Value and returns the decrement value. The decrement operation must be

+ performed using MP safe mechanisms. The state of the return value is not

+ guaranteed to be MP safe.

+

+ @param[in] Value A pointer to the 32-bit value to decrement.

+

+ @return The decrement value.

+

+**/

+UINT32

+EFIAPI

+InternalSyncDecrement (

+ IN volatile UINT32 *Value

+ )

+{

+ UINT32 Temp;

+

+ Temp = *Value;

+ __asm__ __volatile__ (

+ "dbar 0 \n"

+ "amadd.w %1, %2, %0 \n"

+ : "+ZB" (*Value), "=&r" (Temp)

+ : "r" (-1)

+ : "memory"

+ );

+ return *Value;

+}

--
2.27.0


Re: [PATCH v2 27/34] MdePkg/BaseCpuLib: LoongArch Base CPU library implementation.

Chao Li
 

Hi Mike, Liming and Zhiguang,
This patch has not been reviewed, would you please review it?


Thanks,
Chao
--------

On 9月 14 2022, at 5:41 下午, Chao Li <lichao@...> wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053

Implement LoongArch CPU related functions in BaseCpuLib.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Chao Li <lichao@...>
---
MdePkg/Library/BaseCpuLib/BaseCpuLib.inf | 7 ++++++-
MdePkg/Library/BaseCpuLib/BaseCpuLib.uni | 5 +++--
MdePkg/Library/BaseCpuLib/LoongArch/CpuFlushTlb.S | 15 +++++++++++++++
MdePkg/Library/BaseCpuLib/LoongArch/CpuSleep.S | 15 +++++++++++++++
4 files changed, 39 insertions(+), 3 deletions(-)
create mode 100644 MdePkg/Library/BaseCpuLib/LoongArch/CpuFlushTlb.S
create mode 100644 MdePkg/Library/BaseCpuLib/LoongArch/CpuSleep.S

diff --git a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
index c4cd29a783..6b230f6e6d 100644
--- a/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+++ b/MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
@@ -8,6 +8,7 @@
# Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

# Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.<BR>

# Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Portions Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -25,7 +26,7 @@




#

-# VALID_ARCHITECTURES = IA32 X64 EBC ARM AARCH64 RISCV64

+# VALID_ARCHITECTURES = IA32 X64 EBC ARM AARCH64 RISCV64 LOONGARCH64

#



[Sources.IA32]

@@ -61,6 +62,10 @@
[Sources.RISCV64]

RiscV/Cpu.S



+[Sources.LOONGARCH64]

+ LoongArch/CpuFlushTlb.S | GCC

+ LoongArch/CpuSleep.S | GCC

+

[Packages]

MdePkg/MdePkg.dec



diff --git a/MdePkg/Library/BaseCpuLib/BaseCpuLib.uni b/MdePkg/Library/BaseCpuLib/BaseCpuLib.uni
index 80dc495786..7c5c8dfb37 100644
--- a/MdePkg/Library/BaseCpuLib/BaseCpuLib.uni
+++ b/MdePkg/Library/BaseCpuLib/BaseCpuLib.uni
@@ -1,13 +1,14 @@
// /** @file

// Instance of CPU Library for various architecture.

//

-// CPU Library implemented using ASM functions for IA-32, X64 and RISCV64,

+// CPU Library implemented using ASM functions for IA-32, X64, RISCV64 and LoongArch64,

// PAL CALLs for IPF, and empty functions for EBC.

//

// Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.<BR>

// Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

// Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.<BR>

// Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+// Portions Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

//

// SPDX-License-Identifier: BSD-2-Clause-Patent

//

@@ -16,5 +17,5 @@


#string STR_MODULE_ABSTRACT #language en-US "Instance of CPU Library for various architectures"



-#string STR_MODULE_DESCRIPTION #language en-US "CPU Library implemented using ASM functions for IA-32, X64 and RISCV64, PAL CALLs for IPF, and empty functions for EBC."

+#string STR_MODULE_DESCRIPTION #language en-US "CPU Library implemented using ASM functions for IA-32, X64, RISCV64 and LoongArch64, PAL CALLs for IPF, and empty functions for EBC."



diff --git a/MdePkg/Library/BaseCpuLib/LoongArch/CpuFlushTlb.S b/MdePkg/Library/BaseCpuLib/LoongArch/CpuFlushTlb.S
new file mode 100644
index 0000000000..8b792f0a37
--- /dev/null
+++ b/MdePkg/Library/BaseCpuLib/LoongArch/CpuFlushTlb.S
@@ -0,0 +1,15 @@
+#------------------------------------------------------------------------------

+#

+# CpuFlushTlb() for LoongArch64

+#

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

+#

+# SPDX-License-Identifier: BSD-2-Clause-Patent

+#

+#------------------------------------------------------------------------------

+ASM_GLOBAL ASM_PFX(CpuFlushTlb)

+

+ASM_PFX(CpuFlushTlb):

+ tlbflush

+ jirl $zero, $ra, 0

+ .end

diff --git a/MdePkg/Library/BaseCpuLib/LoongArch/CpuSleep.S b/MdePkg/Library/BaseCpuLib/LoongArch/CpuSleep.S
new file mode 100644
index 0000000000..eb31b10714
--- /dev/null
+++ b/MdePkg/Library/BaseCpuLib/LoongArch/CpuSleep.S
@@ -0,0 +1,15 @@
+#------------------------------------------------------------------------------

+#

+# CpuSleep() for LoongArch64

+#

+# Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

+#

+# SPDX-License-Identifier: BSD-2-Clause-Patent

+#

+#------------------------------------------------------------------------------

+ASM_GLOBAL ASM_PFX(CpuSleep)

+

+ASM_PFX(CpuSleep):

+ idle 0

+ jirl $zero, $ra, 0

+ .end

--
2.27.0


Re: [PATCH v2 26/34] MdePkg/BasePeCoff: Add LoongArch PE/Coff related code.

Chao Li
 

Hi Mike, Liming and Zhiguang,
This patch has not been reviewed, would you please review it?


Thanks,
Chao
--------

On 9月 14 2022, at 5:41 下午, Chao Li <lichao@...> wrote:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053

Add LoongArch image relocation.

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>

Signed-off-by: Chao Li <lichao@...>
Co-authored-by: Baoqi Zhang <zhangbaoqi@...>
---
MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 3 +-
.../Library/BasePeCoffLib/BasePeCoffLib.inf | 5 +
.../Library/BasePeCoffLib/BasePeCoffLib.uni | 2 +
.../BasePeCoffLib/LoongArch/PeCoffLoaderEx.c | 137 ++++++++++++++++++
4 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 MdePkg/Library/BasePeCoffLib/LoongArch/PeCoffLoaderEx.c

diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
index 6d8d9faeb8..97a8aaf8c7 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
@@ -1,6 +1,6 @@
/** @file

Base PE/COFF loader supports loading any PE32/PE32+ or TE image, but

- only supports relocating IA32, x64, IPF, ARM, RISC-V and EBC images.

+ only supports relocating IA32, x64, IPF, ARM, RISC-V, LoongArch and EBC images.



Caution: This file requires additional review when modified.

This library will have external input - PE/COFF image.

@@ -18,6 +18,7 @@
Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>

Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+ Portions Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

SPDX-License-Identifier: BSD-2-Clause-Patent



**/

diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
index 110b6d5a09..3b8b8eb191 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
@@ -4,6 +4,7 @@
# The IA32 version library support loading IA32, X64 and EBC PE/COFF images.

# The X64 version library support loading IA32, X64 and EBC PE/COFF images.

# The RISC-V version library support loading RISC-V images.

+# The LoongArch version library support loading LoongArch images.

#

# Caution: This module requires additional review when modified.

# This library will have external input - PE/COFF image.

@@ -13,6 +14,7 @@
# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>

# Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

# Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+# Portions Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

#

# SPDX-License-Identifier: BSD-2-Clause-Patent

#

@@ -46,6 +48,9 @@
[Sources.RISCV64]

RiscV/PeCoffLoaderEx.c



+[Sources.LOONGARCH64]

+ LoongArch/PeCoffLoaderEx.c

+

[Packages]

MdePkg/MdePkg.dec



diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
index 55417029f2..1f731344e1 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.uni
@@ -5,6 +5,7 @@
// The IA32 version library support loading IA32, X64 and EBC PE/COFF images.

// The X64 version library support loading IA32, X64 and EBC PE/COFF images.

// The RISC-V version library support loading RISC-V32 and RISC-V64 PE/COFF images.

+// The LoongArch version library support loading LoongArch32 and LoongArch64 PE/COFF images.

//

// Caution: This module requires additional review when modified.

// This library will have external input - PE/COFF image.

@@ -14,6 +15,7 @@
// Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>

// Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>

// Portions Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights reserved.<BR>

+// Portions Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

//

// SPDX-License-Identifier: BSD-2-Clause-Patent

//

diff --git a/MdePkg/Library/BasePeCoffLib/LoongArch/PeCoffLoaderEx.c b/MdePkg/Library/BasePeCoffLib/LoongArch/PeCoffLoaderEx.c
new file mode 100644
index 0000000000..417096f334
--- /dev/null
+++ b/MdePkg/Library/BasePeCoffLib/LoongArch/PeCoffLoaderEx.c
@@ -0,0 +1,137 @@
+/** @file

+ PE/Coff loader for LoongArch PE image

+

+ Copyright (c) 2022, Loongson Technology Corporation Limited. All rights reserved.<BR>

+

+ SPDX-License-Identifier: BSD-2-Clause-Patent

+**/

+

+#include "BasePeCoffLibInternals.h"

+#include <Library/BaseLib.h>

+

+/**

+ Performs an LoongArch specific relocation fixup and is a no-op on other

+ instruction sets.

+

+ @param[in] Reloc Pointer to the relocation record.

+ @param[in, out] Fixup Pointer to the address to fix up.

+ @param[in, out] FixupData Pointer to a buffer to log the fixups.

+ @param[in] Adjust The offset to adjust the fixup.

+

+ @return Status code.

+

+**/

+RETURN_STATUS

+PeCoffLoaderRelocateImageEx (

+ IN UINT16 *Reloc,

+ IN OUT CHAR8 *Fixup,

+ IN OUT CHAR8 **FixupData,

+ IN UINT64 Adjust

+ )

+{

+ UINT8 RelocType;

+ UINT64 Value;

+ UINT64 Tmp1;

+ UINT64 Tmp2;

+

+ RelocType = (*Reloc) >> 12;

+ Value = 0;

+ Tmp1 = 0;

+ Tmp2 = 0;

+

+ switch (RelocType) {

+ case EFI_IMAGE_REL_BASED_LOONGARCH64_MARK_LA:

+ // The next four instructions are used to load a 64 bit address, relocate all of them

+ Value = (*(UINT32 *)Fixup & 0x1ffffe0) << 7 | // lu12i.w 20bits from bit5

+ (*((UINT32 *)Fixup + 1) & 0x3ffc00) >> 10; // ori 12bits from bit10

+ Tmp1 = *((UINT32 *)Fixup + 2) & 0x1ffffe0; // lu32i.d 20bits from bit5

+ Tmp2 = *((UINT32 *)Fixup + 3) & 0x3ffc00; // lu52i.d 12bits from bit10

+ Value = Value | (Tmp1 << 27) | (Tmp2 << 42);

+ Value += Adjust;

+

+ *(UINT32 *)Fixup = (*(UINT32 *)Fixup & ~0x1ffffe0) | (((Value >> 12) & 0xfffff) << 5);

+ if (*FixupData != NULL) {

+ *FixupData = ALIGN_POINTER (*FixupData, sizeof (UINT32));

+ *(UINT32 *)(*FixupData) = *(UINT32 *)Fixup;

+ *FixupData = *FixupData + sizeof (UINT32);

+ }

+

+ Fixup += sizeof (UINT32);

+ *(UINT32 *)Fixup = (*(UINT32 *)Fixup & ~0x3ffc00) | ((Value & 0xfff) << 10);

+ if (*FixupData != NULL) {

+ *FixupData = ALIGN_POINTER (*FixupData, sizeof (UINT32));

+ *(UINT32 *)(*FixupData) = *(UINT32 *)Fixup;

+ *FixupData = *FixupData + sizeof (UINT32);

+ }

+

+ Fixup += sizeof (UINT32);

+ *(UINT32 *)Fixup = (*(UINT32 *)Fixup & ~0x1ffffe0) | (((Value >> 32) & 0xfffff) << 5);

+ if (*FixupData != NULL) {

+ *FixupData = ALIGN_POINTER (*FixupData, sizeof (UINT32));

+ *(UINT32 *)(*FixupData) = *(UINT32 *)Fixup;

+ *FixupData = *FixupData + sizeof (UINT32);

+ }

+

+ Fixup += sizeof (UINT32);

+ *(UINT32 *)Fixup = (*(UINT32 *)Fixup & ~0x3ffc00) | (((Value >> 52) & 0xfff) << 10);

+ if (*FixupData != NULL) {

+ *FixupData = ALIGN_POINTER (*FixupData, sizeof (UINT32));

+ *(UINT32 *)(*FixupData) = *(UINT32 *)Fixup;

+ *FixupData = *FixupData + sizeof (UINT32);

+ }

+

+ break;

+ default:

+ return RETURN_UNSUPPORTED;

+ }

+

+ return RETURN_SUCCESS;

+}

+

+/**

+ Returns TRUE if the machine type of PE/COFF image is supported. Supported

+ does not mean the image can be executed it means the PE/COFF loader supports

+ loading and relocating of the image type. It's up to the caller to support

+ the entry point.

+

+ @param[in] Machine Machine type from the PE Header.

+

+ @return TRUE if this PE/COFF loader can load the image

+

+**/

+BOOLEAN

+PeCoffLoaderImageFormatSupported (

+ IN UINT16 Machine

+ )

+{

+ if (Machine == IMAGE_FILE_MACHINE_LOONGARCH64) {

+ return TRUE;

+ }

+

+ return FALSE;

+}

+

+/**

+ Performs an LOONGARCH-based specific re-relocation fixup and is a no-op on other

+ instruction sets. This is used to re-relocated the image into the EFI virtual

+ space for runtime calls.

+

+ @param[in] Reloc The pointer to the relocation record.

+ @param[in, out] Fixup The pointer to the address to fix up.

+ @param[in, out] FixupData The pointer to a buffer to log the fixups.

+ @param[in] Adjust The offset to adjust the fixup.

+

+ @return Status code.

+

+**/

+RETURN_STATUS

+PeHotRelocateImageEx (

+ IN UINT16 *Reloc,

+ IN OUT CHAR8 *Fixup,

+ IN OUT CHAR8 **FixupData,

+ IN UINT64 Adjust

+ )

+{

+ // To check

+ return PeCoffLoaderRelocateImageEx (Reloc, Fixup, FixupData, Adjust);

+}

--
2.27.0


回复: 回复: [edk2-devel] [PATCH] UsbNetworkPkg: add USB network devices support

gaoliming
 

Richard:
We are investigating how to get MAC address in USB RNDIS device from open BMC.

For this patch, I find some definitions in Edk2\UsbNetworkPkg\Include\Protocol\UsbEthernetProtocol.h are from the industry spec.
I suggest to move those definitions to new file in Edk2\MdePkg\Include\IndustryStandard directory.

And, for RNDIS driver, I suggest you update the description to specify how it gets network information.

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 RichardHo
[何明忠] via groups.io
发送时间: 2022年9月23日 13:54
收件人: gaoliming <gaoliming@...>; devel@edk2.groups.io;
'Rebecca Cran' <rebecca@...>
抄送: 'Andrew Fish' <afish@...>; 'Leif Lindholm'
<quic_llindhol@...>; 'Michael D Kinney'
<michael.d.kinney@...>; 'Michael Kubacki'
<michael.kubacki@...>; 'Zhiguang Liu' <zhiguang.liu@...>;
TonyLo [羅金松] <TonyLo@...>
主题: Re: 回复: [edk2-devel] [PATCH] UsbNetworkPkg: add USB network
devices support

Hi Liming,

RNDIS specification is not defines this.
We're follow the ECM (5.4 Ethernet Networking Functional Descriptor) and
NCM (5.2.1 NCM Functional Descriptor)specification to implement RNDIS
driver.

If RNDIS device has other way to know the networking functional information.
We could implement the code to GetUsbHeaderFunDescriptor,
GetUsbUnionFunDescriptor, and GetUsbRndisFunDescriptor routine.

Thanks,
Richard

-----Original Message-----
From: gaoliming <gaoliming@...>
Sent: 2022年9月23日 1:03 PM
To: devel@edk2.groups.io; RichardHo [何明忠] <RichardHo@...>;
'Rebecca Cran' <rebecca@...>
Cc: 'Andrew Fish' <afish@...>; 'Leif Lindholm'
<quic_llindhol@...>; 'Michael D Kinney'
<michael.d.kinney@...>; 'Michael Kubacki'
<michael.kubacki@...>; 'Zhiguang Liu' <zhiguang.liu@...>;
TonyLo [羅金松] <TonyLo@...>
Subject: [EXTERNAL] 回复: [edk2-devel] [PATCH] UsbNetworkPkg: add USB
network devices support


**CAUTION: The e-mail below is from an external source. Please exercise
caution before opening attachments, clicking links, or following guidance.**

Richard:
We also verify USB RNDIS module with open BMC. It reports USB RNDIS
device descriptor type is USB_DESC_TYPE_INTERFACE (0x04). It is not
supported by Rndis module.

But in UsbNetworkPkg\Include\Protocol\UsbEthernetProtocol.h, it defines
CS_INTERFACE as 0x24. Rndis module only supports this descriptor type.

So, I want to confirm which specification defines device descriptor type
0x24 and its related structure HEADER_FUN_DESCRIPTOR/
UNION_FUN_DESCRIPTOR/ ETHERNET_FUN_DESCRIPTOR.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 RichardHo
[何明忠] via groups.io
发送时间: 2022年9月7日 13:31
收件人: Rebecca Cran <rebecca@...>; devel@edk2.groups.io
抄送: Andrew Fish <afish@...>; Leif Lindholm
<quic_llindhol@...>; Michael D Kinney
<michael.d.kinney@...>; Michael Kubacki
<michael.kubacki@...>; Zhiguang Liu
<zhiguang.liu@...>; Liming Gao <gaoliming@...>;
TonyLo [羅金松]
<TonyLo@...>
主题: Re: [edk2-devel] [PATCH] UsbNetworkPkg: add USB network devices
support

Hi Rebecca,

We didn't check it in QEMU.
Is QEMU report standard USB RNDIS protocol?

We only test it in physical device. Below is device lists.

USB RNDIS:
AST2500 : BMC report the RNDIS device

USB NCM:
DisplayLink HIS USB3.0 Portable Dock(DisplayLink (UK) Ltd.) Vendor ID:
0x17E9 Product ID: 0x4301

USB ECM:
DM9621(Davicom Semiconductor, Inc.)
Vendor ID: 0x0A46
Product ID: 0x1269

Thanks,
Richard

-----Original Message-----
From: Rebecca Cran <rebecca@...>
Sent: 2022年9月6日 11:05 PM
To: devel@edk2.groups.io; RichardHo [何明忠] <RichardHo@...>
Cc: Andrew Fish <afish@...>; Leif Lindholm
<quic_llindhol@...>; Michael D Kinney
<michael.d.kinney@...>; Michael Kubacki
<michael.kubacki@...>; Zhiguang Liu
<zhiguang.liu@...>; Liming Gao <gaoliming@...>;
TonyLo [羅金松]
<TonyLo@...>
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH] UsbNetworkPkg: add USB
network devices support


**CAUTION: The e-mail below is from an external source. Please
exercise caution before opening attachments, clicking links, or following
guidance.
**

Is it expected that this will work with QEMU (with the usb-net fixes
from
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
u
b.com%2Fmcb30%2Fqemu%2Ftree%2Fusbnet3&amp;data=05%7C01%7Crich
ardho%40ami.com%7C1dd20e124cd64659b4e908da90193dd3%7C27e97857
e15f486cb58e86c2b3040f93%7C1%7C0%7C637980735342252066%7CUnkno
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=xHRQc%2Fnv7fP
k%2BPEVavIlfFpaXj6Gq8NiHUsRdd5HD%2Fc%3D&amp;reserved=0),
for example using the SBSA-REF machine for Arm or OVMF for X64?

I'm adding the following parameters to QEMU:

-netdev user,id=net0,net=192.168.10.0/24,dhcpstart=192.168.10.1
-device
usb-net,netdev=net0


On OVMF I get the following crash when loading UsbRndis.efi after
NetworkCommon.efi:

Support(): UNDI3.1 found on handle 6550D18
Support(): supported on 6550D18
Start(): UNDI3.1 found
!!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID -
00000000 !!!!
RIP - 00000000000B0001, CS - 0000000000000038, RFLAGS -
0000000000000283 RAX - 000000000653AF80, RCX - 00000000065DC382,
RDX
- 0000000000005441 RBX - 00000000065D8000, RSP -
0000000007E8EA48,
RBP - 00000000065DB001 RSI - 0000000000000048, RDI -
0000000006CE82C0
R8 - 0000000007E8EA60, R9 - 0000000007E8EAD0, R10 -
0000000007E8E804
R11 - 0000000000000000, R12 - 8000000000000003, R13 -
0000000000000001
R14 - 0000000006CEE640, R15 - 0000000000000006
DS - 0000000000000030, ES - 0000000000000030, FS -
0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 -
0000000007C01000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 -
0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 -
0000000000000400 GDTR - 00000000079DE000 0000000000000047, LDTR
-
0000000000000000
IDTR - 000000000753C018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 0000000007E8E6A0
!!!! Can't find image information. !!!!


On Arm, I don't get a crash but no network interface gets created.
I've checked the QEMU RNDIS interface is working: if I boot to Linux I
can
get
an IP address and communicate with the outside world.

--
Rebecca Cran


On 9/1/22 23:24, RichardHo [何明忠] via groups.io wrote:
UsbNetworkPkg provides network functions for USB ACM, USB NCM, and
USB
RNDIS network device.

Signed-off-by: Richard Ho <richardho@...>
Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <quic_llindhol@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Michael Kubacki <michael.kubacki@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Liming Gao <gaoliming@...>
Reviewed-by: Tony Lo <tonylo@...>
---
UsbNetworkPkg/Config/UsbNetworkPkg.inc.dsc | 9 +
.../Config/UsbNetworkPkgComponentsDxe.inc.dsc | 20 +
.../Config/UsbNetworkPkgComponentsDxe.inc.fdf | 20 +
.../Config/UsbNetworkPkgDefines.inc.dsc | 23 +
.../Include/Protocol/UsbEthernetProtocol.h | 872 +++++++++
UsbNetworkPkg/NetworkCommon/ComponentName.c | 264 +++
UsbNetworkPkg/NetworkCommon/DriverBinding.c | 583 ++++++
UsbNetworkPkg/NetworkCommon/DriverBinding.h | 263 +++
UsbNetworkPkg/NetworkCommon/NetworkCommon.inf | 43 +
UsbNetworkPkg/NetworkCommon/PxeFunction.c | 1734
+++++++++++++++++
UsbNetworkPkg/ReadMe.md | 65 +
UsbNetworkPkg/ReleaseNotes.md | 11 +
UsbNetworkPkg/UsbCdcEcm/ComponentName.c | 170 ++
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.c | 504
+++++
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.h | 211 ++
UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.inf | 41 +
UsbNetworkPkg/UsbCdcEcm/UsbEcmFunction.c | 861
++++++++
UsbNetworkPkg/UsbCdcNcm/ComponentName.c | 170 ++
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.c | 508
+++++
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.h | 245 +++
UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.inf | 41 +
UsbNetworkPkg/UsbCdcNcm/UsbNcmFunction.c | 946
+++++++++
UsbNetworkPkg/UsbNetworkPkg.dec | 32 +
UsbNetworkPkg/UsbRndis/ComponentName.c | 172 ++
UsbNetworkPkg/UsbRndis/UsbRndis.c | 848
++++++++
UsbNetworkPkg/UsbRndis/UsbRndis.h | 569 ++++++
UsbNetworkPkg/UsbRndis/UsbRndis.inf | 41 +
UsbNetworkPkg/UsbRndis/UsbRndisFunction.c | 1587
+++++++++++++++
28 files changed, 10853 insertions(+)
create mode 100644 UsbNetworkPkg/Config/UsbNetworkPkg.inc.dsc
create mode 100644
UsbNetworkPkg/Config/UsbNetworkPkgComponentsDxe.inc.dsc
create mode 100644
UsbNetworkPkg/Config/UsbNetworkPkgComponentsDxe.inc.fdf
create mode 100644
UsbNetworkPkg/Config/UsbNetworkPkgDefines.inc.dsc
create mode 100644
UsbNetworkPkg/Include/Protocol/UsbEthernetProtocol.h
create mode 100644
UsbNetworkPkg/NetworkCommon/ComponentName.c
create mode 100644
UsbNetworkPkg/NetworkCommon/DriverBinding.c
create mode 100644
UsbNetworkPkg/NetworkCommon/DriverBinding.h
create mode 100644
UsbNetworkPkg/NetworkCommon/NetworkCommon.inf
create mode 100644 UsbNetworkPkg/NetworkCommon/PxeFunction.c
create mode 100644 UsbNetworkPkg/ReadMe.md
create mode 100644 UsbNetworkPkg/ReleaseNotes.md
create mode 100644 UsbNetworkPkg/UsbCdcEcm/ComponentName.c
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.c
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.h
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbCdcEcm.inf
create mode 100644 UsbNetworkPkg/UsbCdcEcm/UsbEcmFunction.c
create mode 100644
UsbNetworkPkg/UsbCdcNcm/ComponentName.c
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.c
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.h
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbCdcNcm.inf
create mode 100644 UsbNetworkPkg/UsbCdcNcm/UsbNcmFunction.c
create mode 100644 UsbNetworkPkg/UsbNetworkPkg.dec
create mode 100644 UsbNetworkPkg/UsbRndis/ComponentName.c
create mode 100644 UsbNetworkPkg/UsbRndis/UsbRndis.c
create mode 100644 UsbNetworkPkg/UsbRndis/UsbRndis.h
create mode 100644 UsbNetworkPkg/UsbRndis/UsbRndis.inf
create mode 100644 UsbNetworkPkg/UsbRndis/UsbRndisFunction.c
-The information contained in this message may be confidential and
proprietary to American Megatrends (AMI). This communication is
intended
to
be read only by the individual or entity to whom it is addressed or by
their
designee. If the reader of this message is not the intended recipient,
you
are
on notice that any distribution of this message, in any form, is
strictly prohibited. Please promptly notify the sender by reply e-mail
or by
telephone
at 770-246-8600, and then delete or destroy all copies of the
transmission.





-The information contained in this message may be confidential and
proprietary to American Megatrends (AMI). This communication is intended to
be read only by the individual or entity to whom it is addressed or by their
designee. If the reader of this message is not the intended recipient, you are
on notice that any distribution of this message, in any form, is strictly
prohibited. Please promptly notify the sender by reply e-mail or by telephone
at 770-246-8600, and then delete or destroy all copies of the transmission.



2521 - 2540 of 96644