| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add helper functions to generate AML Resource Data describing I/O
ranges of four words long. API AmlCodeGenRdQWordIo () is exposed.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
Add API to generate a Name that contains a Unicode string buffer.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
Add API to add a String to a package created with NamedPackage API.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
Add support to add Return objects via AML that pass a single integer
argument to the named method.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
Add API to generate a ThermalZone object to AmlLib.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
The function UsbHcGetPciAddressForHostMem has
ASSERT ((Block != NULL)); and
and the function UsbHcFreeMem has
ASSERT (Block != NULL);
statement after for loop, but these are applicable only in DEBUG mode.
In RELEASE mode, if for whatever reasons there is no match inside for
loop and the loop exits because of Block != NULL; condition, then there
is no "Block" NULL pointer check afterwards and the code proceeds to do
dereferencing "Block" which will lead to CRASH.
Hence, for safety add NULL pointer checks always.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4211
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
The function UhciConvertPollRate has a check
ASSERT (Interval != 0);
but this comes into play only in DEBUG mode. In Release mode, there is
no handling if the Interval parameter value is ZERO. To avoid shifting
by a negative amount later in the code flow in this undesirable case,
it is better to handle it as well by treating it same as if 1 is sent.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4211
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
JsonObjectGetValue() cannot find corresponding JSON value
when the EDKII_JSON_VALUE object is created by another UEFI
driver. This is because "hashtable_seed" is initialized by
current time while JsonLib is loaded. So, "hashtable_seed"
will be different in each individual UEFI driver.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
|
|
InternalLongJump was not returning the 2nd parameter passed
to LongJmp (Value) as the return value from SetJmp.
Seen with code compiled with -Os, where an LongJmp (Buffer, -1)
somehow translated to SetJmp returning 0...
Cc: Yong Li <yong.li@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Tuan Phan <tphan@ventanamicro.com>
Cc: Daniel Schaefer <git@danielschaefer.me>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Create a helper function to query whether ID_AA64MFR1_EL1 indicates
presence of the Virtualization Host Extensions. This feature is only
visible in AARCH64 state.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
|
|
The code can reach line 65 only through the else path above at line 53.
The else path already has the same NULL check at line 55 and hence the
duplicate code lines are totally redundant which can be deleted.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4220
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
Line number 365 does contain a typecast with UINT32, but it is after
all the operations (16-bit left shift followed by OR'ing) are over.
To avoid any SIGN_EXTENSION, typecast the intermediate result after
16-bit left shift operation immediately with UINT32.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4209
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
FEAT_VHE, introduced in ARMv8.1, adds a virtual EL2 timer.
However, this library verifies that exactly 3 or 4 12-byte timer
interrupts are provided in input DT, ASSERTing when the new timer
is added.
Change the assert to >= 36.
Extend the current logic, also initializing PcdArmArchTimerHypVirtIntrNum
if 5 interrupts are provided.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
|
|
PcdArmArchTimerHypVirtIntrNum, defaults to 28 as defined in Arm's
Base System Architecture (current version DEN0094C 1.0C).
Relevant for systems implementing FEAT_VHE, added in ARMv8.1.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Return unsupported HTTP status code to caller so caller can handle
HTTP error status code. Current implementation only return EFI error
to caller. Without knowing the HTTP status code, caller has trouble
to handle HTTP request failure.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Acked-by: Mike Maslenkin <mike.maslenkin@gmail.com>
|
|
Adds a plugin that finds debug macro formatting issues. These errors
often creep into debug prints in error conditions not frequently
executed and make debug more difficult when they are encountered.
The code can be as a standalone script which is useful to find
problems in a large codebase that has not been checked before or as
a build plugin that notifies a developer of an error right away.
The script was already used to find numerous issues in edk2 in the
past so there's not many code fixes in this change. More details
are available in the readme file:
.pytool\Plugin\DebugMacroCheck\Readme.md
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Disables the DebugMacroCheck CI plugin to reduce CI checks performed
in the package.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
|
|
Adds a CI YAML entry to acknowledge a case where custom strings
contain print specifiers for a single debug macro.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Adds a CI YAML entry to acknowledge a case where a macro is expanded
that contains a print specifier.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Adds a CI YAML entry to acknowledge a case where a single argument
is matched to a format specifier with a ternary operator.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
|
|
regex is a popular PIP module for regular expression support.
https://pypi.org/project/regex/
This change adds regex for the upcoming DebugMacroCheck plugin.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Some macros added have a mismatched number of print specifiers to
arguments.
Cc: Abner Chang <abner.chang@amd.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
|
|
When finding a free page range for allocation, if the found range
starts below the tracked memory bin address range, the lowest
memory bin address is updated which will not include the guard page if
present. When CoreConvertPagesWithGuard() is called on the range
being allocated, the memory range is adjusted to include guard
pages which can push it out of the memory bin address range and
cause the memory type statistics to be unaltered.
This patch updates the lowest memory bin address range to account for
the guard page if NeedGuard is TRUE so the memory type statistics
are updated correctly.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Current reset vector uses 0xffffffe0 as AP waking vector, and expects
GenFv generates code aligned on a 4k boundary which will jump to this
location. However, some issues are listed below
1. GenFV doesn't generate code as the comment expects, because GenFv
assumes no modifications are required to the VTF-0 'Volume Top File'.
2. Even if removing VFT0 signature and let GenFv to modify, Genfv is
hard-code using another flash address 0xffffffd0.
3. In the same patch series, AP waking vector code is removed from
GenFv, because no such usage anymore. The existing of first two issues
also approve the usage is not available for a long time.
Therefore, remove AP waking vector related code.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
There are two part of AP waking Vector logic in SecCore.
The first one working with GenFv to find a free 4K aligned space,
use the 4K aligned address as AP waking Vector and jump to 4G-30h,
and finally jump to ApStartup..
The second one hard code uses 4G-1000h as AP waking Vector and
jump to ApStartup.
Both usages are no longer used. Remove them.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494
Today for SEC core(not VTF-0), GenFv finds free 4K aligned space in
FV for AP waking vector and JMP to 4G-30h in the waking vector.
There is no usage of this today. Remove the logic to avoid confusing
and save spaces in reset vector.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
|
|
Direct (fw_cfg) kernel boot works on the RiscVVirt firmware platform too;
I've tested it after extracting the kernel, initrd, and kernel command
line from "openSUSE-Tumbleweed-RISC-V-E20-efi.riscv64.raw". Document this
type of boot, because at least historically, fw_cfg kernel boot was
implemented differently between OVMF and ArmVirtQemu. Thanks: Drew, Sunil.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
"acpi=off" is arguably unusual with UEFI guest OSes; add a note to explain
it. Original explanation by Drew Jones.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Riscv64 KVM services SBI calls internally, so OpenSBI is not used in such
setups. Restrict the "-bios" flag accordingly. Thanks: Andrei, Drew.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: '-bios' is rejected with KVM accel (Drew)]
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=3004
Cc: Qi Zhang <qi1.zhang@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tina Chen <tina.chen@intel.com>
Cc: Xiao X Chen <xiao.x.chen@intel.com>
Signed-off-by: Linus Liu <linus.liu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
|
|
StatementValue->Buffer is converted from ASCII to Unicode by caller
already so we don't have to convert it again.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
|
|
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4527
According to ACPI 6.5 (https://uefi.org/specs/ACPI/6.5/05_ACPI_Software
_Programming_Model.html?highlight=mailboxversion#multiprocessor-wakeup-
structure) the MailBoxVersion is 0.
This patch changed MadtMpWk->MailBoxVersion from 1 to 0 to fix the error.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
|
|
Since I take care of maintaining the contents in RiscVVirt, update my
entry from R to M.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
My usual IA32X64 and X64 builds fail for the NOOPT target, using GCC5:
- IA32X64:
> the required fv image size 0xdef130 exceeds the set fv image size
> 0xd00000
- X64:
> the required fv image size 0xd8f7b8 exceeds the set fv image size
> 0xd00000
NOOPT is important for debugging (less confusing behavior with gdb, and
much less confusing disassembly).
Raise the DXEFV size to 14.5 MB (14 MB would work, but cut it too close
for IA32X64).
After this patch:
- IA32:
> DXEFV [83%Full] 15204352 (0xe80000) total, 12718784 (0xc212c0) used,
> 2485568 (0x25ed40) free
- IA32X64:
> DXEFV [96%Full] 15204352 (0xe80000) total, 14610736 (0xdef130) used,
> 593616 (0x90ed0) free
- X64:
> DXEFV [93%Full] 15204352 (0xe80000) total, 14219192 (0xd8f7b8) used,
> 985160 (0xf0848) free
Tested with:
- IA32, q35, SMM_REQUIRE, Fedora 30 guest
- X64, pc (i440fx), no SMM, RHEL-7.9 guest
- IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest
Test steps (IA32 and X64):
- configure 3 VCPUs
- boot
- run "taskset -c $I efibootmgr" with $I covering 0..2
- systemctl suspend
- resume from virt-manager
- run "taskset -c $I efibootmgr" with $I covering 0..2
Test steps (IA32X64):
- same, but
- start with only 2 cold-plugged CPUs, and
- hot-plug the third VCPU after initial (cold) boot, before the first
"taskset -c $I efibootmgr" invocation
Also compared the verbose IA32 fw log from before the patch vs. the one
after (because IA32 builds even without this patch); the changes look
sane:
> @@ -1,6 +1,6 @@
> SecCoreStartupWithStack(0xFFFCC000, 0x820000)
> SEC: Normal boot
> -DecompressMemFvs: OutputBuffer@A00000+0xDE0090 ScratchBuffer@1800000+0x10000 PcdOvmfDecompressionScratchEnd=0x1810000
> +DecompressMemFvs: OutputBuffer@A00000+0xF60090 ScratchBuffer@1A00000+0x10000 PcdOvmfDecompressionScratchEnd=0x1A10000
> Register PPI Notify: [EfiPeiSecurity2Ppi]
> Install PPI: [EfiFirmwareFileSystem2]
> Install PPI: [EfiFirmwareFileSystem3]
> @@ -28,7 +28,7 @@
> Loading PEIM at 0x000008490C0 EntryPoint=0x0000085639A PlatformPei.efi
> Platform PEIM Loaded
> CMOS:
> -00: 10 00 30 00 13 00 03 12 09 23 26 02 00 80 00 00
> +00: 20 00 41 00 13 00 03 12 09 23 26 02 00 80 00 00
> 10: 00 00 00 00 06 80 02 FF FF 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: FF FF 20 00 00 7F 00 20 30 00 00 00 00 12 00 00
> @@ -70,7 +70,7 @@
> Platform PEI Firmware Volume Initialization
> Install PPI: [EfiPeiFirmwareVolumeInfoPpi]
> Notify: PPI Guid: [EfiPeiFirmwareVolumeInfoPpi], Peim notify entry point: 826554
> -The 1th FV start address is 0x00000900000, size is 0x00D00000, handle is 0x900000
> +The 1th FV start address is 0x00000900000, size is 0x00E80000, handle is 0x900000
> Register PPI Notify: [EfiPeiReadOnlyVariable2Ppi]
> Select Item: 0x19
> Select Item: 0x26
> @@ -90,8 +90,8 @@
> Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF
> Memory Allocation 0x00000000 0x30000 - 0x4FFFF
> Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF
> -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF
> -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF
> +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF
> +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF
> Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF
> Old Stack size 32768, New stack size 131072
> Stack Hob: BaseAddress=0x7AF68000 Length=0x20000
> @@ -196,8 +196,8 @@
> Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF
> Memory Allocation 0x00000000 0x30000 - 0x4FFFF
> Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF
> -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF
> -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF
> +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF
> +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF
> Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF
> Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF
> Memory Allocation 0x00000003 0x7EF50000 - 0x7EF67FFF
> @@ -219,7 +219,7 @@
> Memory Allocation 0x00000003 0x7EE70000 - 0x7EEB2FFF
> Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF
> Memory Allocation 0x00000004 0x7AF68000 - 0x7AF87FFF
> -FV Hob 0x900000 - 0x15FFFFF
> +FV Hob 0x900000 - 0x177FFFF
> InstallProtocolInterface: [EfiDecompressProtocol] 7EEAAA54
> InstallProtocolInterface: [EfiFirmwareVolumeBlockProtocol|EfiFirmwareVolumeBlock2Protocol] 7EB3491C
> InstallProtocolInterface: [EfiDevicePathProtocol] 7EB34990
> @@ -3259,7 +3259,7 @@
> UefiMemory protection: 0x50000 - 0x9E000 Success
> UefiMemory protection: 0x100000 - 0x807000 Success
> UefiMemory protection: 0x808000 - 0x810000 Success
> -UefiMemory protection: 0x1810000 - 0x7AF88000 Success
> +UefiMemory protection: 0x1A10000 - 0x7AF88000 Success
> UefiMemory protection: 0x7AF8B000 - 0x7EB3D000 Success
> UefiMemory protection: 0x7EDBD000 - 0x7EDCF000 Success
> UefiMemory protection: 0x7EE4F000 - 0x7EF68000 Success
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
"OvmfPkg/Include/IndustryStandard/Virtio095.h" defines the macro
VIRTIO_SUBSYSTEM_CONSOLE with value 3; other locations in the tree already
use it (such as ArmVirtPkg/PlatformBootManagerLib,
OvmfPkg/VirtioSerialDxe). We should use it in
OvmfPkg/PlatformBootManagerLib too, rather than the naked constant 3.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Jake reports that the IS_ARM_MEMORY_REGION_ATTRIBUTES_SECURE() macro is
no longer accurate since commit 852227a9d52e3cb9 ("ArmPkg/Mmu: Remove
handling of NONSECURE memory regions").
Fortunately, it only affects the NS bit in level 1 short descriptors,
which is ignored when executing in non-secure mode. And given that
running UEFI in the secure world is not a use case we aim to support,
let's just drop this logic altogether.
Reported-by: Jake Garver <jake@nvidia.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
Explain how users can compose their pre-OS environment purely from
binaries they've built themselves.
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
Many arrays are defined with a length of MAX_MENU_NUMBER in
FormGuid.h. Two of those are BootOptionOrder and DriverOptionOrder.
In UpdatePage.c, a pointer is set to either of those arrays. The
array buffer is accessed using an index whose range is checked after
the pointer to the array is dereferenced. This change moves the check
before the dereference.
In another place in the file, the ConsoleCheck pointer is also set to
an array buffer with MAX_MENU_NUMBER elements. Only an ASSERT()
currently checks the range of the array index. This change
conditionalizes the pointer dereference itself on the range of Index.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
|
|
Update reviewers and maintainers for DynamicTablesPkg
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
|
FvbDev->LbaCache must be freed on error path before freeing FvbDev.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
FwVolHeader must be freed on error path.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
The immediately preceding call, GetBestLanguage, plus the implementation of
HiiGetString, which is called immediately afterwards, make it clear that
BestLanguage is a null-terminated ASCII string, and not just a five byte,
non-null terminated buffer.
Therefore AsciiStrLen is one byte too short, meaning that whether the space
allocated is really sufficient and whether the resultant string is really
null-terminated becomes implementation-dependent. Rather than switching to
AsciiStrSize, we use an explicitly compile-time string length calculation
(both compile-time and run-time approaches are currently used elsewhere in
the codebase for copying static strings).
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4505
This gives something like ~3 fold throughput boost.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Saloni Kasbekar <saloni.kasbekar@intel.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4547
Add New Intel Processor family for SMBIOS Type 4
Hex value - 16h
Name - Intel(R) Processor
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Benny Lin <benny.lin@intel.com>
Cc: Gua Guo <gua.guo@intel.com>
Cc: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Avinash Bhargava <avinash.bhargava@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Add a .editorconfig file which editors can use for basic formatting
details of files, such as tabs/spaces, line endings etc.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
If OVMF fails to find the RSDP in memory, it should fall back installing
the statically provided ACPI tables.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
|
|
Moves the range check for the index into the array before attempting
any accesses using the array index.
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
|
|
Removes the comparison since unsigned values are always greater than
or equal to 0.
See the following CodeQL query for more info:
/cpp/cpp-unsigned-comparison-zero/
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?idD91
mAvailableAlgoArray is currently allocated for "RNG_AVAILABLE_ALGO_MAX"
number of bytes, whereas it was dereferenced as "EFI_RNG_ALGORITHM".
This change fixed the buffer allocation logic by allocating a proper size
of buffer before referencing.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Kun Qin <kuqin@microsoft.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
|
