Jeff Fan [Wed, 1 Apr 2015 07:51:15 +0000 (07:51 +0000)]
SourceLevelDebugPkg: Use CPU Local APIC timer to handle timeout.
Use CPU Local APIC timer to handle timeout when read data from debug port, instead of the TimerLib in Debug Communication lib instances.
It could remove much duplicated code in Debug Communication Lib instances.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17089 6f19259b-4bc3-4df7-8a09-765794883524
Liming Gao [Tue, 31 Mar 2015 08:24:58 +0000 (08:24 +0000)]
MdeModulePkg: Remove unused internal structure in PeiCore
PeiCore calls REPORT_STATUS_CODE_WITH_EXTENDED_DATA() with its internal structure for Image
dispatcher. No code consumes it. But, it brings confuse.
DxeCore and SmmCore calls REPORT_STATUS_CODE_WITH_EXTENDED_DATA() with Handle only.
To be consistent, update PeiCore to be same to DxeCore and SmmCore.
Maurice Ma [Tue, 31 Mar 2015 01:06:23 +0000 (01:06 +0000)]
Pkg-Module: CorebootModulePkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootModulePkg is the source code package of coreboot support modules that will be used to parse the coreboot tables and report memory/io resources.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17084 6f19259b-4bc3-4df7-8a09-765794883524
Maurice Ma [Tue, 31 Mar 2015 01:03:03 +0000 (01:03 +0000)]
Pkg-Module: CorebootModulePkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootModulePkg is the source code package of coreboot support modules that will be used to parse the coreboot tables and report memory/io resources.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17082 6f19259b-4bc3-4df7-8a09-765794883524
Maurice Ma [Tue, 31 Mar 2015 00:56:01 +0000 (00:56 +0000)]
Pkg-Module: CorebootPayloadPkg
Initial coreboot UEFI payload code check in. It provides UEFI services on top of coreboot that allows UEFI OS boot.
CorebootPayloadPkg is source code package of coreboot Payload Modules, Provides definitions of payload image's layout and lists the modules required in DSC file.
It supports the following features:
- Support Unified Extensible Firmware Interface (UEFI) specification 2.4.
- Support Platform Initialization(PI) specification 1.3.
- Support execution as a coreboot payload.
- Support USB 3.0
- Support SATA/ATA devices.
- Support EFI aware OS boot.
The following features are not supported currently and have not been validated:
- GCC Tool Chains
- SMM Execution Environment
- Security Boot
It was tested on a Intel Bay Trail CRB platform.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Prince Agyeman <prince.agyeman@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17081 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Fri, 27 Mar 2015 21:25:16 +0000 (21:25 +0000)]
OvmfPkg: XenConsoleSerialPortLib: deal with output overflow
It is the responsibility of the SerialPortLib implementation
to deal with flow control if the underlying medium cannot keep
up with the inflow of data.
So in our SerialPortWrite () function, we should spin as long
as we need to in order to deliver all the data instead of giving
up and returning a smaller value than the number of bytes we were
given. Also, remove the 'if (Sent > 0)' condition on the signalling
of the event channel: if the buffer is full and we haven't been able
to add any more data, it makes perfect sense to signal the event
channel again, even if we have done so before when we did write
the data.
Also, this patch brings the implementation of XenSerialPortLib
in sync with the library class documentation.
Ard Biesheuvel [Fri, 27 Mar 2015 17:27:14 +0000 (17:27 +0000)]
MdePkg: fix ARM version of InternalMathSwapBytes64 ()
The ARM asm implementation of InternalMathSwapBytes64 () does
interesting things if bit 7 of operand r1 (upper 32 bits of the
input value) is set. After the recursive swap, bit 7 ends up in
the sign bit position, after which it is right shifted with sign
extension, and or'ed with the upper half of the output value.
This means SwapBytes64 (0x00000080_00000000) returns an incorrect
value of 0xFFFFFFFF_80000000.
Gabriel Somlo [Thu, 26 Mar 2015 19:06:07 +0000 (19:06 +0000)]
OvmfPkg: Q35: Use correct ACPI PM control register:bit
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Fu Siyuan [Thu, 26 Mar 2015 04:49:30 +0000 (04:49 +0000)]
PXE driver bug fix.
1. Update the parameter check of PXE.UdpRead() to align with spec definition.
2. Update PXE driver to use EFI_PXE_BASE_CODE_UDP_OPFLAGS_ANY_DEST_IP when calling UdpRead to receive server discovery message.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17075 6f19259b-4bc3-4df7-8a09-765794883524
Brian J. Johnson [Wed, 25 Mar 2015 01:51:23 +0000 (01:51 +0000)]
PeCoffExtraActionLibDebug: Restore debug registers in PeCoffExtraActionLibDebug
PeCoffExtraActionLibDebug uses the debug registers to pass module load information to the
DebugAgent, then restores the old register values.
However, it was missing code to restore Dr7 in the
DEBUG_LOAD_IMAGE_METHOD_SOFT_INT3 case. This broke hardware breakpoints and watchpoints.
It could also lose modifications the debugger made to Cr4.
Restore the Dr7 and Cr4 values correctly in the
DEBUG_LOAD_IMAGE_METHOD_SOFT_INT3 case, as well as the
DEBUG_LOAD_IMAGE_METHOD_IO_HW_BREAKPOINT case.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brian J. Johnson <bjohnson@sgi.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17071 6f19259b-4bc3-4df7-8a09-765794883524
Cinnamon Shia [Mon, 23 Mar 2015 05:39:51 +0000 (05:39 +0000)]
NT32Pkg: Fix build errors from building secure boot with NT32 X64
Root cause: The CryptoPkg\Library\IntrinsicLib needs override MSFT build option to remove /Oi and /GL,
but it doesn’t work because of the build option override in Nt32Pkg.dsc.
Solution: Remove /X in BaseTools/Conf/tools_def.template
Laszlo Ersek [Mon, 16 Mar 2015 19:57:34 +0000 (19:57 +0000)]
OvmfPkg: include XHCI driver
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.
Laszlo Ersek [Mon, 16 Mar 2015 19:57:06 +0000 (19:57 +0000)]
ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
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.
Laszlo Ersek [Mon, 16 Mar 2015 19:56:54 +0000 (19:56 +0000)]
ArmVirtualizationPkg: build UEFI shell from source
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.
Elvin Li [Mon, 16 Mar 2015 02:41:48 +0000 (02:41 +0000)]
MdeModulePkg: Add SMBIOS 64-bit support for SMBIOS 3.0.
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
Tapan Shah [Mon, 9 Mar 2015 22:18:59 +0000 (22:18 +0000)]
ShellPkg: Help and Error Messages Update
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.
Star Zeng [Mon, 9 Mar 2015 13:05:55 +0000 (13:05 +0000)]
SecurityPkg Variable: Keep the behavior of Variable Dxe and SMM drivers consistent
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.
Star Zeng [Mon, 9 Mar 2015 13:03:42 +0000 (13:03 +0000)]
MdeModulePkg Variable: Keep the behavior of Variable Dxe and SMM drivers consistent
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.
Chen Fan [Mon, 9 Mar 2015 06:45:26 +0000 (06:45 +0000)]
UefiCpuPkg/MpSerivce: add volatile qualifiers
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
Chen Fan [Mon, 9 Mar 2015 06:43:11 +0000 (06:43 +0000)]
UefiCpuPkg/MpService: Put APs to sleep when not busy.
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
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@17022 6f19259b-4bc3-4df7-8a09-765794883524
Chen Fan [Mon, 9 Mar 2015 06:37:32 +0000 (06:37 +0000)]
UefiCpuPkg/MpService: fix trivial typo in cpu state
CpuStateBuzy => CpuStateBusy
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@17021 6f19259b-4bc3-4df7-8a09-765794883524
Ard Biesheuvel [Fri, 6 Mar 2015 02:58:01 +0000 (02:58 +0000)]
MdeModulePkg: use 64 KB granularity for runtime allocations on AArch64
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.
Ard Biesheuvel [Fri, 6 Mar 2015 02:57:11 +0000 (02:57 +0000)]
MdeModulePkg: serve allocations from higher-up bins if current bin is empty
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.
Ard Biesheuvel [Fri, 6 Mar 2015 02:56:20 +0000 (02:56 +0000)]
MdeModulePkg: carve pool pages into the largest chunks possible
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.
Ard Biesheuvel [Fri, 6 Mar 2015 02:55:35 +0000 (02:55 +0000)]
MdeModulePkg: use index to traverse free pool pages
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.
Ard Biesheuvel [Fri, 6 Mar 2015 02:54:50 +0000 (02:54 +0000)]
MdeModulePkg: improve scalability of memory pools
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.
Ard Biesheuvel [Fri, 6 Mar 2015 02:54:05 +0000 (02:54 +0000)]
MdeModulePkg: use correct granularity when allocating pool pages
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
(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.
Laszlo Ersek [Tue, 3 Mar 2015 08:13:40 +0000 (08:13 +0000)]
OvmfPkg: replace strict XenHypercallLib construction with explicit query
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.
Laszlo Ersek [Tue, 3 Mar 2015 08:13:19 +0000 (08:13 +0000)]
OvmfPkg: XenHypercallLib: add empty constructor for ARM & AARCH64
In the next patch we'll add a simple query function to the XenHypercallLib
library class that is supposed to be called by initialization code in
modules. Among those, in constructors of dependent libraries too.
Library construction ordering is ensured only between libraries with
constructors, plus we shouldn't allow a dependent library with a
constructor to call into any XenHypercallLib instances (the simple query
function) before XenHypercallLib is constructed itself. For this reason,
introduce an (empty) constructor for ARM & AARCH64 too.
Laszlo Ersek [Mon, 2 Mar 2015 16:19:41 +0000 (16:19 +0000)]
ArmVirtualizationPkg: expose debug message bitmask on build command line
This enables -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F style command line
options.
Since we're massaging the debug message bitmask anyway, let's update the
description of the individual bits too in the comments, so that they match
"MdePkg/Include/Library/DebugLib.h".
Laszlo Ersek [Mon, 2 Mar 2015 16:19:36 +0000 (16:19 +0000)]
ArmVirtualizationPkg: PlatformIntelBdsLib: lack of QEMU kernel is no error
When the user doesn't pass a kernel with QEMU's "-kernel" switch, the
firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize
key; there's no way to distinguish "no kernel" from "zero sized kernel".
In both cases TryRunningQemuKernel() proceeds as far as gBS->LoadImage(),
which then rejects the zero sized synthetic file with EFI_UNSUPPORTED.
This is known and works fully as expected; however we should rather catch
the much more frequent "no kernel" case earlier, in order to avoid the
EFI_D_ERROR message
TryRunningQemuKernel: LoadImage(): Unsupported
which is arguably meaningless noise for the "no kernel" case.
Laszlo Ersek [Mon, 2 Mar 2015 16:19:32 +0000 (16:19 +0000)]
ArmPlatformPkg: PEIM startup is not an error
"MemoryInitPeim.c" and "PlatformPeim.c" log startup messages on the
EFI_D_ERROR level. This clutters a strictly EFI_D_ERROR level log
needlessly; change the log bitmask of these messages to EFI_D_LOAD |
EFI_D_INFO.
Laszlo Ersek [Mon, 2 Mar 2015 16:19:26 +0000 (16:19 +0000)]
ArmPkg: DebugPeCoffExtraActionLib: debugger commands are not errors
PeCoffLoaderRelocateImageExtraAction() prints helpful debugger commands
for source level debugging. These messages should not be printed on the
EFI_D_ERROR level; they don't report errors. Change the debug level
(bitmask, actually) to EFI_D_LOAD | EFI_D_INFO, because the messages are
printed in relation to image loading, and they are informative.
Ard Biesheuvel [Sat, 28 Feb 2015 20:34:26 +0000 (20:34 +0000)]
ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen,xen" DT node
This patchs adds support to VirtFdtDxe for the Xen DT node which
contains the base address of the Grant Table. This data is communicated
to XenBusDxe using a XENIO_PROTOCOL instance.
Ard Biesheuvel [Sat, 28 Feb 2015 20:34:16 +0000 (20:34 +0000)]
ArmVirtualizationPkg: add XenIoMmioLib
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Ard Biesheuvel [Sat, 28 Feb 2015 20:34:06 +0000 (20:34 +0000)]
Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI
device but an abstract 'platform' device. Add a dedicated Vendor
Hardware device path GUID to identify this node.
Ard Biesheuvel [Sat, 28 Feb 2015 20:33:55 +0000 (20:33 +0000)]
ArmVirtualizationPkg: implement dummy RealTimeClockLib for Xen
This implements a dummy RealTimeClockLib for Xen, as there is no
guest interface to access the time kept by Xen that can be shared
between UEFI and the OS.
Ard Biesheuvel [Sat, 28 Feb 2015 20:33:45 +0000 (20:33 +0000)]
Ovmf/Xen: add Xen PV console SerialPortLib driver
This implements a SerialPortLib instance that wires up to the
PV console ring used by domU guests. Also imports the required
upstream Xen io/console.h header.
Ard Biesheuvel [Sat, 28 Feb 2015 20:33:34 +0000 (20:33 +0000)]
Ovmf/Xen: port XenBusDxe to other architectures
This patch updates XenBusDxe to use the 16-bit compare and exchange
function that was introduced for this purpose to the
BaseSynchronizationLib. It also provides a new generic implementation
of TestAndClearBit () using the same 16-bit compare and exchange, making
this module fully architecture agnostic.
Ard Biesheuvel [Sat, 28 Feb 2015 20:33:11 +0000 (20:33 +0000)]
Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
projects / mirror_edk2.git / log