to handle the case PE file alignment is not same as PE section alignment.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17063 6f19259b-4bc3-4df7-8a09-765794883524
smbiosview can dump 64-bit entry point and table
as long as SMBIOS 3.0 table exists in system configuration table.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17060 6f19259b-4bc3-4df7-8a09-765794883524
check IsDeleteAuthVariable () first and then check
UserPhysicalPresent () to avoid the case below.
PcdSetXX (a DynamicHii PCD) -> gRT->SetVariable ()
-> UserPhysicalPresent () -> PcdGetXX ()
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17058 6f19259b-4bc3-4df7-8a09-765794883524
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer
TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now
drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as
XHCI emulation is reportedly more virtualization-friendly than EHCI,
consuming less CPU.
The driver can be tested with the following QEMU command line options:
-device nec-usb-xhci -device usb-kbd
This patch should not regress existing QEMU command lines (ie. trigger an
ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's
"-device nec-usb-xhci" has never before resulted in USB devices that
worked with edk2 firmware builds, hence users have never had a reason to
add that option.
Now that they learn about XHCI support in OVMF by reading this commit
message, they (or their packagers) will also know to update qemu to
aa685789 or later (in practice that means the upcoming 2.3 release), at
least if they want to use '-device nec-usb-xhci' with edk2, for the first
time ever.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Alexander Graf <agraf@suse.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17055 6f19259b-4bc3-4df7-8a09-765794883524
The "virt" machine type of qemu-system-(arm|aarch64) had no PCIe support
prior to qemu commit
4ab29b82 arm: Add PCIe host bridge in virt machine
With that commit, the "virt" board acquired the capability to expose an
XHCI controller. Using a USB keyboard as example, the command line options
were
-device nec-usb-xhci -device usb-kbd
However, due to a slight XHCI emulation bug in QEMU -- dating back to
several years earlier -- edk2's XHCI driver would encounter a failed
ASSERT().
This emulation problem has been fixed in QEMU commit
aa685789 xhci: generate a Transfer Event for each Transfer TRB with the
IOC bit set
and now edk2's XHCI driver works well on QEMU's "nec-usb-xhci" device.
Let's enable the driver in ArmVirtualizationQemu, as XHCI emulation is
reportedly more virtualization-friendly than EHCI, consuming less CPU.
(ArmVirtualizationXen is not modified because it includes no USB-related
drivers at all.)
This patch should not regress existing QEMU command lines (ie. expose the
failed ASSERT()) because QEMU's "-device nec-usb-xhci" has never before
resulted in USB devices that worked with edk2 firmware builds, hence users
have never had a reason to add that option.
Now that they learn about XHCI support in ArmVirtualizationQemu by reading
this commit message, they (or their packagers) will also know to update
qemu to aa685789 or later (in practice that means the upcoming 2.3
release), at least if they want to use '-device nec-usb-xhci' with edk2,
for the first time ever.
Cc: Leif Lindholm <Leif.Lindholm@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17053 6f19259b-4bc3-4df7-8a09-765794883524
Including a prebuilt shell executable in the firmware binary is suboptimal
practice, especially given that the source code of the UEFI shell resides
in the same edk2 tree. Benefits of building the shell from source are
partly technical (a developer patching the shell can actually see the
results), partly ideological (the nominally built-from-source firmware is
actually built from source). "Security" might be worth a mention too.
The stanza for the [Components.common] section of
"ArmVirtualization.dsc.inc" originates from under OvmfPkg.
Cc: Leif Lindholm <Leif.Lindholm@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17052 6f19259b-4bc3-4df7-8a09-765794883524
Add SMBIOS 64-bit entry point and 64-bit table support for SMBIOS 3.0.
Introduce PcdSmbiosEntryPointProvideMethod to produce 32-bit or 64-bit
SMBIOS table.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17051 6f19259b-4bc3-4df7-8a09-765794883524
The restriction of UsbHc2.SyncInterruptTransfer() on interrupt transfer direction is removed. This interface could support Interrupt IN/OUT now.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17041 6f19259b-4bc3-4df7-8a09-765794883524
Increase the BiosID VERSION_MINOR to 02.
Modified some PCDs as PcdsDynamicEx, and modified FSP support API.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tim He <tim.he@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17035 6f19259b-4bc3-4df7-8a09-765794883524
Updates to various profile commands help and error message output with better wordings.
Fix few inconsistency issues found in error messages across various profile commands.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hp.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17032 6f19259b-4bc3-4df7-8a09-765794883524
to return EFI_NOT_FOUND when a specified variable doesn't exist and
Data parameter is NULL but DataSize parameter is valid in GetVariable() invocation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17031 6f19259b-4bc3-4df7-8a09-765794883524
to return EFI_NOT_FOUND when a specified variable doesn't exist and
Data parameter is NULL but DataSize parameter is valid in GetVariable() invocation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17030 6f19259b-4bc3-4df7-8a09-765794883524
For avoid the compiler optimizing the code, we let Parameter and Procedure in CpuData volatile.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17024 6f19259b-4bc3-4df7-8a09-765794883524
Add a new sleeping state for APs, when no procedure execution, put AP to sleep. when need to execute
procedure, only need to wake up this AP by sent SIPI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17023 6f19259b-4bc3-4df7-8a09-765794883524
On AArch64, the OS can choose to run with a page size of 64 KB,
making it cumbersome to deal with UEFI reserved memory regions
whose boundaries are not 64 KB aligned.
So increase the allocation granularity for runtime regions to
64 KB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17016 6f19259b-4bc3-4df7-8a09-765794883524
This patch changes the allocation logic for the pool allocator to only
allocate additional pages if the requested allocation cannot be fulfilled
from the current bin or any of the larger ones. If there are larger blocks
available, they will be used to serve the allocation, and the remainder will
be carved up into smaller blocks using the existing carving up logic.
Note that all pool sizes are a multiple of the smallest pool size, so it is
guaranteed that the remainder will be carved up without spilling. Due to the
exponential nature of the pool sizes, the amount of work is logarithmic in
the size of the available block.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17015 6f19259b-4bc3-4df7-8a09-765794883524
In preparation of the next patch, that serves allocations from higher-up
bins if the current bin is depleted, this patch updates the carving up
strategy to populate the largest bins first. To ensure that there will
always be an allocation of the appropriate size made, the current allocation
request is served first from the newly allocated memory region.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17014 6f19259b-4bc3-4df7-8a09-765794883524
In preparation of making the pool code capable of serving allocations
from higher-up bins, update the free path to traverse a candidate page
by following the index of POOL_FREE header instead of duplicating the
carving logic that was used at page allocation time. This allows chunks
to be split into smaller ones, where one can be returned to serve the
allocation, and the other stored in a smaller bin for later use.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17013 6f19259b-4bc3-4df7-8a09-765794883524
The existing linear mapping between allocation size and pool index
does not scale when moving to a 64 KB granularity or beyond. With
a granularity of 64 KB, 2048 (!) bins will be created for each
memory type, each differing 32 bytes in size with the next one.
Instead, introduce an exponential scheme where each bin size is
the sum of the two previous ones.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17012 6f19259b-4bc3-4df7-8a09-765794883524
After fixing the sanity check on the alignment of the runtime regions
in SVN revision #16630 ("MdeModulePkg/DxeMain: Fix wrong sanity check
in CoreTerminateMemoryMap()"), it is no longer possible to define a
runtime allocation alignment that is different from the boot time
allocation alignment.
For instance, #defining the following in MdeModulePkg/Core/Dxe/Mem/Imem.h
will hit the ASSERT () in MdeModulePkg/Core/Dxe/Mem/Page.c:1798
#define EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT (SIZE_64KB)
#define DEFAULT_PAGE_ALLOCATION (EFI_PAGE_SIZE)
(which is needed for 64-bit ARM to adhere to the Server Base Boot
Requirements [SBBR], which stipulates that all runtime memory regions
should be naturally aligned multiples of 64 KB)
This patch fixes this use case by ensuring that the backing for the memory
pools is allocated in appropriate chunks for the memory type.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17011 6f19259b-4bc3-4df7-8a09-765794883524
Fixed smbiosview to use correct value to parse Type 27.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Shumin Qiu <shumin.qiu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17007 6f19259b-4bc3-4df7-8a09-765794883524
XenHypercallLib has two clients at the moment: XenBusDxe and
XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86
platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib
instance built into it fails to initialize, which triggers an ASSERT() in
auto-generated code.
Instead, let's call XenHypercallIsAvailable() in the driver's entry point,
and exit cleanly when the driver is started on a non-Xen platform.
Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't
proceed if Xen is not available. In practice this check should never fail,
because XenConsoleSerialPortLib is only used on ARM, and
ArmXenHypercallLib is always available; but nonetheless we should be
pedantic.
Reported-by: Gabriel L. Somlo <gsomlo@gmail.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17001 6f19259b-4bc3-4df7-8a09-765794883524
Similarly to QemuFwCfgLib, we prefer mellow library construction code and
an explicit "are you available" query function in the XenHypercallLib
class. In this step we introduce that query function, but move no client
code to it yet.
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng
Fu Siyuan
Hao Wu
Elvin Li
Qiu Shumin
Laszlo Ersek
Feng Tian
Liming Gao
David Wei
Tim He
Shifei Lu
Tapan Shah
Chen Fan
Mang Guo
Ard Biesheuvel
Hot Tian
Yao, Jiewen
Ma, Maurice