Commit Graph

28610 Commits

Author SHA1 Message Date
Jiahui Cen via groups.io 7a6172f88b OvmfPkg: Introduce PciHostBridgeUtilityLib class
Introduce a new PciHostBridgeUtilityLib class to share duplicate code
between OvmfPkg and ArmVirtPkg.

Extract function PciHostBridgeUtilityResourceConflict from
PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib.

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

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
2021-01-20 16:14:20 +00:00
GregX Yeh ca272b9513 DxeHttpIoLib: Http boot failure with no initializes timeout value.
https://bugzilla.tianocore.org/show_bug.cgi?id=3170
Using PcdHttpIoTimeout to set default timeout value to HttpIoLib.

Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: GregX Yeh <gregx.yeh@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
2021-01-20 12:33:38 +00:00
Laszlo Ersek 6e55868631 ArmVirtPkg: disable list length checks in NOOPT and DEBUG builds
In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero,
then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list
length against the PCD.

This turns the time complexity of node-level APIs from constant to linear,
and that of full-list manipulations from linear to quadratic.

(See some example OVMF numbers in the previous patch.)

Checking list lengths against an arbitrary maximum -- default value, and
current ArmVirtPkg setting: 1,000,000 -- seems useless even in NOOPT and
DEBUG builds, while the cost is significant; so set the PCD to 0.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-11-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek d3f3c94201 OvmfPkg: disable list length checks in NOOPT and DEBUG builds
In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero,
then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list
length against the PCD.

This turns the time complexity of node-level APIs from constant to linear,
and that of full-list manipulations from linear to quadratic.

As an example, consider the EFI_SHELL_FILE_INFO list, which is a data
structure that's widely used in the UEFI shell. I randomly extracted 5000
files from "/usr/include" on my laptop, spanning 1095 subdirectories out
of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are
the wall-clock times:

           PcdMaximumLinkedListLength  PcdMaximumLinkedListLength
           =1,000,000                  =0
           --------------------------  ---------------------------
FAT        4 min 31 s                        18 s
virtio-fs  5 min 13 s                  1 min 33 s

Checking list lengths against an arbitrary maximum (default: 1,000,000)
seems useless even in NOOPT and DEBUG builds, while the cost is
significant; so set the PCD to 0.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-10-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek c8ce60eb29 ShellPkg/ShellProtocol: sort files by FullName in RemoveDupInFileList()
The current implementation of EfiShellRemoveDupInFileList():
- has quadratic time complexity, as a disadvantage, and
- needs no dynamic memory, as an advantage.

Because the UEFI Shell Spec requires
EFI_SHELL_PROTOCOL.RemoveDupInFileList() to succeed at all times, keep the
current method as a fallback (it cannot fail due to needing no dynamic
memory).

However, as a higher priority option, call the new ShellSortFileList()
function at first, separating out and releasing duplicates.
(ShellSortFileList() can fail due to EFI_OUT_OF_RESOURCES.)

Beyond improving the runtime of EfiShellRemoveDupInFileList(), this change
has the extremely desirable effect that the ShellOpenFileMetaArg()
function in the ShellPkg/Library/UefiShellLib instance will produce file
lists that are sorted by FullName.

Consequently, when used with wildcards, the ATTRIB, CP, FOR, LOAD,
LOADPCIROM, LS, MV, RM, TOUCH, TYPE commands will process files in
FullName order. (LS in recursive mode uses wildcards internally.)

Before:

> FS2:\> dir -r -sfo apps
> [...]
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\X64"
> FileInfo,"FS2:\apps\AARCH64"
> FileInfo,"FS2:\"
> FileInfo,"FS2:\apps\IA32"
> FileInfo,"FS2:\apps\X64\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\X64\SmiHandlerProfileInfo.efi"
> FileInfo,"FS2:\apps\X64\"
> FileInfo,"FS2:\apps\X64\VariableInfo.efi"
> FileInfo,"FS2:\apps\X64\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\X64\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\X64\Cpuid.efi"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\AARCH64\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\AARCH64\"
> FileInfo,"FS2:\apps\AARCH64\VariableInfo.efi"
> FileInfo,"FS2:\apps\AARCH64\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\AARCH64\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\IA32\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\IA32\SmiHandlerProfileInfo.efi"
> FileInfo,"FS2:\apps\IA32\"
> FileInfo,"FS2:\apps\IA32\VariableInfo.efi"
> FileInfo,"FS2:\apps\IA32\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\IA32\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\IA32\Cpuid.efi"
> FileInfo,"FS2:\apps\"

After:

> FS2:\> dir -r -sfo apps
> [...]
> FileInfo,"FS2:\"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\AARCH64"
> FileInfo,"FS2:\apps\IA32"
> FileInfo,"FS2:\apps\X64"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\AARCH64\"
> FileInfo,"FS2:\apps\AARCH64\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\AARCH64\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\AARCH64\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\AARCH64\VariableInfo.efi"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\IA32\"
> FileInfo,"FS2:\apps\IA32\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\IA32\Cpuid.efi"
> FileInfo,"FS2:\apps\IA32\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\IA32\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\IA32\SmiHandlerProfileInfo.efi"
> FileInfo,"FS2:\apps\IA32\VariableInfo.efi"
> FileInfo,"FS2:\apps\"
> FileInfo,"FS2:\apps\X64\"
> FileInfo,"FS2:\apps\X64\AcpiViewApp.efi"
> FileInfo,"FS2:\apps\X64\Cpuid.efi"
> FileInfo,"FS2:\apps\X64\DumpDynPcd.efi"
> FileInfo,"FS2:\apps\X64\MemoryProfileInfo.efi"
> FileInfo,"FS2:\apps\X64\SmiHandlerProfileInfo.efi"
> FileInfo,"FS2:\apps\X64\VariableInfo.efi"

Regarding LS in non-SFO mode, the stability of ShellSortFileList() shows.
The ShellSortFileList() call added to LS in the previous patch re-sorts
the output of ShellOpenFileMetaArg(); and so this patch improves the
ordering between identical FileNames:

Before:

> FS2:\> dir -r apps
> Directory of: FS2:\apps\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53 <DIR>         4,096  AARCH64
> 12/22/2020  17:53 <DIR>         4,096  IA32
> 12/22/2020  17:53 <DIR>         4,096  X64
>           0 File(s)           0 bytes
>           5 Dir(s)
> Directory of: FS2:\apps\X64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
>           6 File(s)     256,192 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\AARCH64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
>           4 File(s)     233,472 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\IA32\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
>           6 File(s)     224,768 bytes
>           2 Dir(s)
>
> FS2:\> dir apps\*\*.efi
> Directory of: FS2:\apps\*\
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
>          16 File(s)     714,432 bytes
>           0 Dir(s)

After:

> FS2:\> dir -r apps
> Directory of: FS2:\apps\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53 <DIR>         4,096  AARCH64
> 12/22/2020  17:53 <DIR>         4,096  IA32
> 12/22/2020  17:53 <DIR>         4,096  X64
>           0 File(s)           0 bytes
>           5 Dir(s)
> Directory of: FS2:\apps\AARCH64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
>           4 File(s)     233,472 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\IA32\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
>           6 File(s)     224,768 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\X64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
>           6 File(s)     256,192 bytes
>           2 Dir(s)
>
> FS2:\> dir apps\*\*.efi
> Directory of: FS2:\apps\*\
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
>          16 File(s)     714,432 bytes
>           0 Dir(s)

Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-9-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek 70254306a8 ShellPkg/Ls: sort output by FileName in non-SFO mode
Sorting the LS output in non-SFO mode by FileName is best demonstrated
with two examples.

(1a) Before:

> FS2:\> dir -r apps
> Directory of: FS2:\apps\
> 01/01/1970  01:00 <DIR> r           0  .
> 12/22/2020  17:53 <DIR>         4,096  X64
> 12/22/2020  17:53 <DIR>         4,096  AARCH64
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53 <DIR>         4,096  IA32
>           0 File(s)           0 bytes
>           5 Dir(s)
> Directory of: FS2:\apps\X64\
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 01/01/1970  01:00 <DIR> r           0  .
> 12/22/2020  17:52              11,456  VariableInfo.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 01/01/1970  01:00 <DIR> r           0  ..
>           6 File(s)     256,192 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\AARCH64\
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 01/01/1970  01:00 <DIR> r           0  .
> 12/22/2020  17:52              20,480  VariableInfo.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 01/01/1970  01:00 <DIR> r           0  ..
>           4 File(s)     233,472 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\IA32\
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 01/01/1970  01:00 <DIR> r           0  .
> 12/22/2020  17:52              10,880  VariableInfo.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 01/01/1970  01:00 <DIR> r           0  ..
>           6 File(s)     224,768 bytes
>           2 Dir(s)

(1b) After:

> FS2:\> dir -r apps
> Directory of: FS2:\apps\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53 <DIR>         4,096  AARCH64
> 12/22/2020  17:53 <DIR>         4,096  IA32
> 12/22/2020  17:53 <DIR>         4,096  X64
>           0 File(s)           0 bytes
>           5 Dir(s)
> Directory of: FS2:\apps\X64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
>           6 File(s)     256,192 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\AARCH64\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
>           4 File(s)     233,472 bytes
>           2 Dir(s)
> Directory of: FS2:\apps\IA32\
> 01/01/1970  01:00 <DIR> r           0  .
> 01/01/1970  01:00 <DIR> r           0  ..
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
>           6 File(s)     224,768 bytes
>           2 Dir(s)

(2a) Before:

> FS2:\> dir apps\*\*.efi
> Directory of: FS2:\apps\*\
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
>          16 File(s)     714,432 bytes
>           0 Dir(s)

(2b) After:

> FS2:\> dir apps\*\*.efi
> Directory of: FS2:\apps\*\
> 12/22/2020  17:53             126,656  AcpiViewApp.efi
> 12/22/2020  17:53             139,264  AcpiViewApp.efi
> 12/22/2020  17:53             105,536  AcpiViewApp.efi
> 12/22/2020  17:53              38,784  Cpuid.efi
> 12/22/2020  17:53              36,096  Cpuid.efi
> 12/22/2020  17:52              18,752  DumpDynPcd.efi
> 12/22/2020  17:52              32,768  DumpDynPcd.efi
> 12/22/2020  17:52              17,344  DumpDynPcd.efi
> 12/22/2020  17:52              26,304  MemoryProfileInfo.efi
> 12/22/2020  17:52              40,960  MemoryProfileInfo.efi
> 12/22/2020  17:52              24,192  MemoryProfileInfo.efi
> 12/22/2020  17:52              34,240  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              30,720  SmiHandlerProfileInfo.efi
> 12/22/2020  17:52              11,456  VariableInfo.efi
> 12/22/2020  17:52              20,480  VariableInfo.efi
> 12/22/2020  17:52              10,880  VariableInfo.efi
>          16 File(s)     714,432 bytes
>           0 Dir(s)

(In example (2), note that the sorting is stable; that is, whatever order
is established between identical FileNames by ShellOpenFileMetaArg(), it
is preserved by ShellSortFileList().)

Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-8-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek 101c55ac0d ShellPkg/ShellCommandLib: add ShellSortFileList()
Introduce the ShellSortFileList() function, for sorting an
EFI_SHELL_FILE_INFO list, by FileName or by FullName.

Duplicates can be kept in the same list, or separated out to a new list.
In either case, the relative order between duplicates does not change (the
sorting is stable).

For the sorting, use OrderedCollectionLib rather than SortLib:

- The PerformQuickSort() function from the latter has quadratic worst-case
  time complexity, plus it is implemented recursively (see
  "MdeModulePkg/Library/UefiSortLib/UefiSortLib.c"). It can also not
  return an error on memory allocation failure.

- In comparison, the Red-Black Tree instance of OrderedCollectionLib sorts
  in O(n*log(n)) worst-case time, contains no recursion with the default
  PcdValidateOrderedCollection=FALSE setting, and the OrderedCollectionLib
  class APIs return errors appropriately.

The OrderedCollectionLib APIs do not permit duplicates natively, but by
using lists as collection entries, stable sorting of duplicates can be
achieved.

Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek ef03e72651 UefiPayloadPkg: add OrderedCollectionLib class resolution
A subsequent patch in the series will make the

  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf

instance dependent on the OrderedCollectionLib class. Because the shell
binary in this platform consumes the above UefiShellCommandLib instance,
resolve OrderedCollectionLib.

Cc: Benjamin You <benjamin.you@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210113085453.10168-6-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek 130e929f98 EmulatorPkg: add OrderedCollectionLib class resolution
A subsequent patch in the series will make the

  ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf

instance dependent on the OrderedCollectionLib class. Because the shell
binary in this platform consumes the above UefiShellCommandLib instance,
resolve OrderedCollectionLib.

Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210113085453.10168-5-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-01-19 18:23:28 +00:00
Laszlo Ersek a0b352e18b ArmVirtPkg: raise PcdShellFileOperationSize to 128KB
Some UEFI shell commands read and write files in chunks. The chunk size is
given by "PcdShellFileOperationSize", whose default in
"ShellPkg/ShellPkg.dec" is 4KB (0x1000).

The virtio-fs daemon of QEMU advertizes a 128KB maximum buffer size by
default, for the FUSE_WRITE operation.

By raising PcdShellFileOperationSize 32-fold, the number of FUSE write
requests shrinks proportionately, when writing large files. And when a
Virtio Filesystem is not used, a 128KB chunk size is still not
particularly wasteful.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3125
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek 2912341cd9 OvmfPkg: raise PcdShellFileOperationSize to 128KB
Some UEFI shell commands read and write files in chunks. The chunk size is
given by "PcdShellFileOperationSize", whose default in
"ShellPkg/ShellPkg.dec" is 4KB (0x1000).

The virtio-fs daemon of QEMU advertizes a 128KB maximum buffer size by
default, for the FUSE_WRITE operation.

By raising PcdShellFileOperationSize 32-fold, the number of FUSE write
requests shrinks proportionately, when writing large files. And when a
Virtio Filesystem is not used, a 128KB chunk size is still not
particularly wasteful.

Some ad-hoc measurements on my laptop, using OVMF:

- The time it takes to copy a ~270MB file from a Virtio Filesystem to the
  same Virtio Filesystem improves from ~9 seconds to ~1 second.

- The time it takes to compare two identical ~270MB files on the same
  Virtio Filesystem improves from ~11 seconds to ~3 seconds.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3125
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20210113085453.10168-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Laszlo Ersek f72fd9616e ShellPkg/Comp: add file buffering
The COMP shell command compares two files byte for byte. In order to
retrieve the bytes to compare, it currently invokes
gEfiShellProtocol->ReadFile() on both files, using a single-byte buffer
every time. This is very inefficient; the underlying
EFI_FILE_PROTOCOL.Read() function may be costly.

Read both file operands in chunks of "PcdShellFileOperationSize" bytes.
Draw bytes for comparison from the internal read-ahead buffers.

Some ad-hoc measurements on my laptop, using OVMF, and the 4KB default of
"PcdShellFileOperationSize":

- When comparing two identical 1MB files that are served by EnhancedFatDxe
  on top of VirtioScsiDxe, this patch brings no noticeable improvement;
  the comparison completes in <1s both before and after.

- When comparing two identical 1MB files served by VirtioFsDxe, the
  comparison time improves from 2 minutes 25 seconds to <1s.

Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3123
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2021-01-19 18:23:28 +00:00
Igor Druzhinin e68c2a22ca OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on Xen
We faced a problem with passing through a PCI device with 64GB BAR to UEFI
guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G
address which pushes physical address space to 37 bits. That is above
36-bit width that OVMF exposes currently to a guest without tweaking
PcdPciMmio64Size knob.

The reverse calculation using this knob was inhereted from QEMU-KVM
platform code where it serves the purpose of finding max accessible
physical address without necessary trusting emulated CPUID physbits value
(that could be different from host physbits). On Xen we expect to use
CPUID policy to level the data correctly to prevent situations with guest
physbits > host physbits e.g. across migrations.

The next aspect raising concern - resource consumption for DXE IPL page
tables and time required to map the whole address space in case of using
CPUID bits directly. That could be mitigated by enabling support for 1G
pages in DXE IPL configuration. 1G pages are available on most CPUs
produced in the last 10 years and those without don't have many phys bits.

Remove all the redundant code now (including PcdPciMmio64.. handling
that's not used on Xen anyway) and grab physbits directly from CPUID that
should be what baremetal UEFI systems do.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Julien Grall <julien@xen.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
[lersek@redhat.com: fix up authorship from groups.io-mangled From line]
[lersek@redhat.com: wrap commit message at 74 characters]
2021-01-19 17:00:08 +00:00
Lou, Yun 83facfd184 UefiCpuPkg/CpuCacheInfoLib: Add new CpuCacheInfoLib.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105

This new library uses a platform agnostic algorithm to get CPU
cache information. It provides user with an API(GetCpuCacheInfo)
to get detailed CPU cache information by each package, each core
type included in this package, and each cache level & type.
This library can be used by code that produces SMBIOS_TABLE_TYPE7
SMBIOS table.

Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
2021-01-19 14:03:04 +00:00
Jason Lou 79f3404ad8 MdePkg/Cpuid.h: Add CPUID_HYBRID_INFORMATION Leaf(1Ah).
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3105

The UefiCpuPkg/CpuCacheInfoLib will reference new definition
about CPUID_HYBRID_INFORMATION Leaf(1Ah).

Signed-off-by: Jason Lou <yun.lou@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-19 14:03:04 +00:00
Ard Biesheuvel 4f214830ce ArmPlatformPkg/NorFlashDxe: use correct PCD accessors
Commit 8015f3f6d4 ("ArmPlatformPkg: Enable support for flash in
64-bit address space") updated the NorFlash DXE and StMM drivers to
take alternate PCDs into account when discovering the base of the
NOR flash regions.

This introduced a disparity between the declarations of the PCD references
in the .INF files, which permits the use of dynamic PCDs, and the code
itself, which now uses FixedPcdGet() accessors. On platforms that actually
use dynamic PCDs, this results in a build error.

So let's clean this up:
- for the DXE version, use the generic PcdGet() accessors, so dynamic PCDs
  are permitted
- for the standalone MM version, redeclare the PCDs as [FixedPcd] in the
  .INF description, and switch to the FixedPcdGet() accessors.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
2021-01-18 11:19:45 +00:00
Ard Biesheuvel 7dc277f9e4 Maintainers: update Ard's email address
I will no longer work for ARM as of next month, and will therefore
lose access to my @arm.com email account. I intend to remain active
in the Tianocore project nonetheless, so let's update my email accounts
to one that is not tied to my current or future employer.

Cc: <ardb+tianocore@kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Sami Mujawar <sami.mujawar@arm.com>
2021-01-18 09:40:29 +00:00
Zarcd Zhong a7ef2a03b9 MdeModulePkg/PciBusDxe: Handle BAR sizing fail in high 32bit of MEM64.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3149

Address MEM64 BAR in type unknown if sizing fail in high 32bit.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Zarcd Zhong <zarcd.zhong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-18 01:38:29 +00:00
Abner Chang c88736f860 EmulatorPkg/library: RedfishPlatformCredentialLib
Platform specific implementation of acquiring credential
to access to Redfish service. This is the platform library
which incorporates with Redfish Credential DXE driver under
Redfish package.

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Acked-by: Ray Ni <ray.ni@intel.com>
2021-01-16 03:35:31 +00:00
wenyi,xie via groups.io 014b9850f2 MdeModulePkg/FileExplorerLib: Add return value check
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3113
According to FAT specification, the length of file path
should not larger than 260. When the length exceed 260,
function FatLocateOFile will return EFI_INVALID_PARAMETER
and the parameter FileHandle will be NULL. Then on the
top-level function?an exception happens when the NULL
pointer is passed and be used.
So adding return value check after calling
LibGetFileHandleFromMenu, if return value is not success,
stop calling LibFindFiles.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
2021-01-15 01:08:45 +00:00
Abner Chang 40c4cd5421 NetworkPkg/DxeHttpLib: Migrate HTTP header manipulation APIs
Move HTTP header manipulation functions to DxeHttpLib from
HttpBootSupport.c. These general functions are used by both
Http BOOT and RedfishLib (patches will be sent later).

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Fan Wang <fan.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
2021-01-14 14:54:12 +00:00
Bob Feng 536a3e6726 BaseTools: Fix the build report crash issue
In the following corner case, the build report
will crash. This patch is to fix this problem.

Case:
Multiple SKU are used and 2 more DynamicHii structure Pcds
are set in dsc file under different SKU. And 1 more of those
Pcds are not used in any INF file.

Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
2021-01-14 04:12:09 +00:00
Luo, Heng da45a36087 MdeModulePkg: Update UNI file for PCIe Resizable BAR Capability
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3138

PcdPcieResizableBarSupport was added in MdeModulePkg.dec, update
UNI file as the documentation of the PCD.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-14 01:34:16 +00:00
Luo, Heng ef23012e54 MdeModulePkg: Change default value of PcdPcieResizableBarSupport to FALSE
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3138

Change default value of PcdPcieResizableBarSupport to FALSE, avoid it
impacts existing platforms.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-14 01:34:16 +00:00
Guo Dong ebfe2d3eb5 UefiCpuPkg/CpuDxe: Fix boot error
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3084

When DXE drivers are dispatched above 4GB memory in 64bit
mode, the address setCodeSelectorLongJump in stack will
be override by parameter. Jump to Qword is not supported
by some processors. So use "o64 retf" instead.

Signed-off-by: Guo Dong <guo.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-12 06:35:30 +00:00
Guo Dong edd74ad3ad UefiCpuPkg/MpInitLib: Fix a hang in above 4GB case
This patch fixed the hang in UEFICpuPkg when it is dispatched above 4GB.
In UEFI BIOS case CpuInfoInHob is provided to DXE under 4GB from PEI.
When using UEFI payload and bootloaders, CpuInfoInHob will be allocated
above 4GB since it is not provided from bootloader. so we need update
the code to make sure this hob could be accessed correctly in this case.

Signed-off-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2021-01-12 06:35:30 +00:00
Zeng, Star e992cc3f48 UefiCpuPkg PiSmmCpuDxeSmm: Reduce SMRAM consumption in CpuS3.c
This patch makes two refinements to reduce SMRAM consumption in CpuS3.c.
1. Only do CopyRegisterTable() when register table is not empty,
  IsRegisterTableEmpty() is created to check whether the register table
  is empty or not.

  Take empty PreSmmInitRegisterTable as example, about 24K SMRAM consumption
  could be reduced when mAcpiCpuData.NumberOfCpus=1024.
  sizeof (CPU_REGISTER_TABLE) = 24
  mAcpiCpuData.NumberOfCpus = 1024 = 1K
  mAcpiCpuData.NumberOfCpus * sizeof (CPU_REGISTER_TABLE) = 24K

2. Only copy table entries buffer instead of whole buffer.
  AllocatedSize in SourceRegisterTableList is the whole buffer size.
  Actually, only the table entries buffer needs to be copied, and the size
  is TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY).

  Take AllocatedSize=0x1000=4096, TableLength=100 and NumberOfCpus=1024 as example,
  about 1696K SMRAM consumption could be reduced.
  sizeof (CPU_REGISTER_TABLE_ENTRY) = 24
  TableLength = 100
  TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 2400
  AllocatedSize = 0x1000 = 4096
  AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY) = 4096 - 2400 = 1696
  NumberOfCpus = 1024 = 1K
  NumberOfCpus * (AllocatedSize - TableLength * sizeof (CPU_REGISTER_TABLE_ENTRY)) = 1696K

This patch also corrects the CopyRegisterTable() function description.

Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210111015419.28368-1-star.zeng@intel.com>
2021-01-11 09:13:48 +00:00
Rebecca Cran a8a0831589 ShellPkg: Remove bogus "Bits" text from some smbiosview strings.
Neither of the "CPU Socket Unpopulated" or "Do not reboot" messages
should contain the word "Bits".

Remove them and update the identifier for the "Do not reboot" message
to remove the word "BITS".

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2021-01-11 02:09:10 +00:00
Nhi Pham 4ea3a6ded8 EmbeddedPkg/RealTimeClockRuntimeDxe: depend on gEfiVariableArchProtocolGuid
The EfiGetVariable() is used in the entry of this module. So, the
variable services are required to be ready before they are used. This
patch adds the arch protocol gEfiVariableArchProtocolGuid to dependency
expression to guarantee that this module will be started once the
variable protocol is available.

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
2021-01-10 01:18:44 +00:00
Abner Chang acabf1b033 .pytool: Add required submodule for JsonLib
Open source project jansson is leveraged by edk2 JsonLib.
Add jansson to the required submodule in CiSettings.py.

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Abner Chang fa4c4fb8cd RedfishPkg: Add EDK2 port of jansson library to build
Add EDK2 port jansson library (JsonLib) to RedfishPkg

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Abner Chang ea830b96fd RedfishPkg/library: EDK2 port of jansson library
edk2 JsonLib which is the edk2 port of open source
jansson library.
(https://github.com/akheron/jansson)
jansson library is the open source project to manipulate
JSON data structure.

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Abner Chang 6e9233f968 RedfishPkg/RedfishCrtLib: Redfish C runtime library
Redfish CRT library is currently used by edk2 JsonLib
(open source jansson project) and edk2 RedfishLib
(libredfish open source project). Redfish CrtLib library
provides the necessary C runtime equivalent edk2 functions
for open source projects.

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Abner Chang a88731d545 edk2: jansson submodule for edk2 JSON library
Add git submodule "jansson" library, which is the open
source project (https://github.com/akheron/jansson) used
to manipulate JSON data structure. jansson library is
wrapped as edk2 JsonLib and the use cases will be the
edk2 Redfish feature drivers and edk2 port of libredfish
(https://github.com/DMTF/libredfish).
jansson open source project is under MIT license.
(refer to ReadMe.rst under edk2).

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Abner Chang 805b8b8837 RedfishPkg/Ucs2Utf8lib: UCS2 to UFT8 manipulation library
This library provides UCS2 to UFT8 or vise versa functions to
manipulate UCS2/UTF8 strings. This library is currently used
by edk2 port of open source jansson library.

Signed-off-by: Abner Chang <abner.chang@hpe.com>

Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Nickle Wang <nickle.wang@hpe.com>
Cc: Peter O'Hanley <peter.ohanley@hpe.com>
Reviewed-by: Nickle Wang <nickle.wang@hpe.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2021-01-09 03:08:51 +00:00
Leif Lindholm 9783767fcf OvmfPkg: add TimeBaseLib resolution for OvmfXen
Commit 55ee36b0c4
("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib")
added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks
build of OvmfXen.dsc.

Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2021-01-08 15:54:44 +00:00
Leif Lindholm fabeffb09e EmbeddedPkg: add TimeBaseLib resolution to EmbeddedPkg.dsc
Commit 55ee36b0c4
("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib")
added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks
build of EmbeddedPkg.dsc.

Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf.

Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Nhi Pham <nhi@os.amperecomputing.com>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
2021-01-08 14:02:03 +00:00
Ard Biesheuvel 1819817155 EmbeddedPkg/PrePiMemoryAllocationLib: use correct size for pool hob
Use the correct type in the sizeof() expression to calculate the size
of the newly allocated EFI_HOB_MEMORY_POOL hob.

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3139
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
2021-01-08 13:37:57 +00:00
Liu, WeiX C 7e6776deaf MdeModulePkg Lzma: Update LZMA SDK version to 19.00
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3101
New formal release in https://www.7-zip.org/sdk.html is 19.00.

Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Wei Liu <weix.c.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-01-08 10:03:53 +00:00
Liu, WeiX C 4e38bb607a BaseTools LzmaCompress: Update LZMA to new 19.00 version
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3101
New formal release in https://www.7-zip.org/sdk.html is 19.00.

Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Wei Liu <weix.c.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-01-08 10:03:53 +00:00
Marc Moisson-Franckhauser 1d3d5e3256 ShellPkg/Acpiview: AEST Parser
Bugzilla: 3048 (https://bugzilla.tianocore.org/show_bug.cgi?id=3048)

Add a new parser for the Arm Error Source Table (AEST) described in
the ACPI for the Armv8 RAS Extensions 1.1 Platform Design Document,
dated 28 September 2020.
(https://developer.arm.com/documentation/den0085/0101/)

AEST enables kernel-first handling of errors in a system that supports
the Armv8 RAS extensions. It covers Armv8.2+ RAS extensions for PEs
and the RAS system architecture for non-PE system components.

Signed-off-by: Marc Moisson-Franckhauser <marc.moisson-franckhauser@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
2021-01-08 03:50:34 +00:00
Marc Moisson-Franckhauser a955c6f97f MdePkg/IndustryStandard: AEST Table definition
Bugzilla: 3049 (https://bugzilla.tianocore.org/show_bug.cgi?id=3049)

Add definition for the Arm Error Source Table (AEST) described in
the ACPI for the Armv8 RAS Extensions 1.1 Platform Design Document,
dated 28 September 2020.
(https://developer.arm.com/documentation/den0085/0101/)

Signed-off-by: Marc Moisson-Franckhauser <marc.moisson-franckhauser@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
2021-01-08 03:50:34 +00:00
Tom Lendacky 85b8eac59b OvfmPkg/VmgExitLib: Validate #VC MMIO is to un-encrypted memory
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

When SEV-ES is active, and MMIO operation will trigger a #VC and the
VmgExitLib exception handler will process this MMIO operation.

A malicious hypervisor could try to extract information from encrypted
memory by setting a reserved bit in the guests nested page tables for
a non-MMIO area. This can result in the encrypted data being copied into
the GHCB shared buffer area and accessed by the hypervisor.

Prevent this by ensuring that the MMIO source/destination is un-encrypted
memory. For the APIC register space, access is allowed in general.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0cf28470ad5e694af45f7f0b35296628f819567d.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky 362654246a OvmfPkg/PlatformPei: Reserve GHCB backup pages if S3 is supported
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

Protect the GHCB backup pages used by an SEV-ES guest when S3 is
supported.

Regarding the lifecycle of the GHCB backup pages:
  PcdOvmfSecGhcbBackupBase

(a) when and how it is initialized after first boot of the VM

  If SEV-ES is enabled, the GHCB backup pages are initialized when a
  nested #VC is received during the SEC phase
  [OvmfPkg/Library/VmgExitLib/SecVmgExitVcHandler.c].

(b) how it is protected from memory allocations during DXE

  If S3 and SEV-ES are enabled, then InitializeRamRegions()
  [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with an AcpiNVS
  memory allocation HOB, in PEI.

  If S3 is disabled, then these ranges are not protected. PEI switches to
  the GHCB backup pages in permanent PEI memory and DXE will use these
  PEI GHCB backup pages, so we don't have to preserve
  PcdOvmfSecGhcbBackupBase.

(c) how it is protected from the OS

  If S3 is enabled, then (b) reserves it from the OS too.

  If S3 is disabled, then the range needs no protection.

(d) how it is accessed on the S3 resume path

  It is rewritten same as in (a), which is fine because (b) reserved it.

(e) how it is accessed on the warm reset path

  It is rewritten same as in (a).

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <119102a3d14caa70d81aee334a2e0f3f925e1a60.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky 5667dc43d8 OvmfPkg/VmgExitLib: Support nested #VCs
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

In order to be able to issue messages or make interface calls that cause
another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support
for nested #VCs.

In order to support nested #VCs, GHCB backup pages are required. If a #VC
is received while currently processing a #VC, a backup of the current GHCB
content is made. This allows the #VC handler to continue processing the
new #VC. Upon completion of the new #VC, the GHCB is restored from the
backup page. The #VC recursion level is tracked in the per-vCPU variable
area.

Support is added to handle up to one nested #VC (or two #VCs total). If
a second nested #VC is encountered, an ASSERT will be issued and the vCPU
will enter CpuDeadLoop ().

For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory
layout, with two new fixed PCDs to provide the address and size of the
backup area.

For PEI/DXE, the GHCB backup pages are allocated as boot services pages
using the memory allocation library.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky c330af0246 OvmfPkg/MemEncryptSevLib: Address range encryption state interface
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

Update the MemEncryptSevLib library to include an interface that can
report the encryption state on a range of memory. The values will
represent the range as being unencrypted, encrypted, a mix of unencrypted
and encrypted, and error (e.g. ranges that aren't mapped).

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0d98f4d42a2b67310c29bac7bcdcf1eda6835847.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky a746ca5b47 OvmfPkg/MemEncryptSevLib: Make the MemEncryptSevLib available for SEC
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

In preparation for a new interface to be added to the MemEncryptSevLib
library that will be used in SEC, create an SEC version of the library.

This requires the creation of SEC specific files.

Some of the current MemEncryptSevLib functions perform memory allocations
which cannot be performed in SEC, so these interfaces will return an error
during SEC. Also, the current MemEncryptSevLib library uses some static
variables to optimize access to variables, which cannot be used in SEC.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <bc7fa76cc23784ab3f37356b6c10dfec61942c38.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky 60b195d257 OvmfPkg/MemEncryptSevLib: Coding style fixes in prep for SEC library
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

Creating an SEC version of the library requires renaming an existing file
which will result in the existing code failing ECC. Prior to renaming the
existing file, fix the coding style to avoid the ECC failure.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <f765d867da4a703e0a0db35e26515a911482fd40.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky 31f5ebd6db OvmfPkg/VmgExitLib: Check for an explicit DR7 cached value
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

Check the DR7 cached indicator against a specific value. This makes it
harder for a hypervisor to just write random data into that field in an
attempt to use an invalid DR7 value.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <65157c1155a9c058c43678400dfc0b486e327a3e.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00
Tom Lendacky 84cddd7082 OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108

The PCIe MMCONFIG range should be treated as an MMIO range. However,
there is a comment in the code explaining why AddIoMemoryBaseSizeHob()
is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo
or NonExistent type memory and will clear the encryption bit for these
ranges.

Since the MMCONFIG range does not have one of these types, the encryption
bit is not cleared for this range. Add support to detect the presence of
the MMCONFIG range and clear the encryption bit. This will be needed for
follow-on support that will validate that MMIO is not being performed to
an encrypted address range under SEV-ES.

Even though the encryption bit was set for this range, this still worked
under both SEV and SEV-ES because the address range is marked by the
hypervisor as MMIO in the nested page tables:
- For SEV, access to this address range triggers a nested page fault (NPF)
  and the hardware supplies the guest physical address (GPA) in the VMCB's
  EXITINFO2 field as part of the exit information. However, the encryption
  bit is not set in the GPA, so the hypervisor can process the request
  without any issues.
- For SEV-ES, access to this address range triggers a #VC. Since OVMF runs
  identity mapped (VA == PA), the virtual address is used to avoid the
  lookup of the physical address. The virtual address does not have the
  encryption bit set, so the hypervisor can process the request without
  any issues.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:34:39 +00:00