Matt Fleming [Tue, 24 Sep 2013 18:33:56 +0000 (18:33 +0000)]
OvmfPkg: EFI handover flags are in Bp->hdr.xloadflags
LoadLinux() is looking at the wrong field for the kernel's EFI handover
protocol flags. It's not currently possible for JumpToUefiKernel() to
ever be called (even accidentally) because BIT2 and BIT3 of
Bp->hdr.load_flags are never set in modern kernels, which means that
control is always transferred to the kernel via the legacy entry point.
Look at the correct field so that the EFI handover protocol is used
whenever it's available.
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: David Woodhouse <David.Woodhouse@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14721 6f19259b-4bc3-4df7-8a09-765794883524
Jordan Justen [Tue, 24 Sep 2013 18:23:20 +0000 (18:23 +0000)]
OvmfPkg: Add platform specific reset vector code for X64
KVM has a bug that prevents using page tables in the ROM if the ROM
region utilizes the KVM READONLY memory feature. Therefore, we
avoid using page tables stored in the ROM.
Since OVMF doesn't require memory initialization, we just build
page table entries in RAM at 0x80000 very early in the OVMF boot
process. This address is just after the 'temp RAM' which is set
up by the SEC module.
Currently we only set up 4GB of page tables for OVMF's PEI,
but DxeIpl will build identity mapped page tables that cover all
of the available processor physical address space.
Reported-by: Gary Ching-Pang Lin <glin@suse.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14715 6f19259b-4bc3-4df7-8a09-765794883524
Jordan Justen [Tue, 24 Sep 2013 18:23:09 +0000 (18:23 +0000)]
UefiCpuPkg/ResetVector/Vtf0: Move Page Table/CR3 setting to a new file
Now, Transition32FlatTo64Flat calls SetCr3ForPageTables64
which is located in Ia32/PageTables64.asm.
This change is required so OVMF can replace the code in
Ia32/PageTables64.asm with code that generates page tables in
RAM.
Note: Since this change does not impact the functionality of the
current VTF0 binaries, they are not being updated. The resulting
new binaries were tested to verify there is no regression.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14714 6f19259b-4bc3-4df7-8a09-765794883524
Olivier Martin [Mon, 23 Sep 2013 09:20:03 +0000 (09:20 +0000)]
EdkShellPkg: Add Aarch64 support
* Update the EFI Shell patch to use SVN rev 64 (was rev 61)
* Modify build system to enable compilation targeting Aarch64 platform.
* Modify patch to apply on EdkShell sources to add support for Aarch64.
build.py...
/.../OvmfPkg/OvmfPkgX64.dsc(...): error 4000: Instance of library class [TpmMeasurementLib] is not found
in [/.../SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf] [X64]
consumed by module [/.../MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf]
Let's provide a library instance for TpmMeasurementLib the same way as
"SecurityPkg/SecurityPkg.dsc" does (SVN r13964.)
Fu Siyuan [Wed, 18 Sep 2013 02:27:20 +0000 (02:27 +0000)]
Fix a bug in Ip4 driver that Ip4.Transmit() interface may return EFI_INVALID_PARAMETER without restore TPL. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Jin Eric <eric.jin@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14682 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni [Tue, 17 Sep 2013 05:11:30 +0000 (05:11 +0000)]
Fix 3 bugs in DiskIoDxe and PartitionDxe drivers introduced in DiskIo2 implementation.
1. DiskIo2 shouldn't signal the event when the *Ex interface returns failure status per the UEFI spec.
2. PartitionDxe should close DiskIo2 protocol when error happens in DriverBindingStart() otherwise Fat driver cannot open the DiskIo2 BY_DRIVER.
3. PartitionDxe should create event using TPL_NOTIFY instead of TPL_CALLBACK otherwise asynchronous FileIo may be blocked.
At least for AARCH64 currently, SystemMemoryTop and FdTop can overflow
while adding the 32-bit PCDs together. The resulting value loses the
upper 32-bits. Cast each of the values to EFI_PHYSICAL_ADDRESS size
before doing the addition to prevent erroneous overflow. There is currently
no 32-bit platform in EDKII open source that will overflow and this change
would not fix that problem anyway.
Jeff Fan [Mon, 16 Sep 2013 08:42:59 +0000 (08:42 +0000)]
1. Read 32bit CPU Init APIC ID from CPUID leaf B in XAPIC mode.
2. Read CPU APIC ID from CPUID leaf B in case CPU Init APIC ID is larger 255 in XAPIC mode.
Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14674 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuBootOrder: keep some boot options that have not been selected
Some of the active boot options that have not been selected over fw_cfg
should be preserved at the end of the boot order. For now we're adding
back everything that starts with neither PciRoot() nor HD(). This includes
the UEFI shell, memory-mapped from the firmware image.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg: QemuBootOrder: collect active UEFI boot options in advance
In preparation for the next patch, collect active UEFI boot options in
advance into a new array. Rebase the current inner loop (the matching
loop) to this array.
OvmfPkg: QemuBootOrder: expand relative device paths in UEFI boot options
The prefix matching logic in Match()
[OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
to specify full (absolute) device paths. However, partial (relative)
device paths starting with a HD() node are valid for booting. By not
recognizing them, QemuBootOrder.c misses (and deletes) valid boot options
that would otherwise match the user's preference.
Just like BdsLibBootViaBootOption() expands such paths with the
BdsExpandPartitionPartialDevicePathToFull() function for booting, do the
same in QemuBootOrder.c for prefix matching.
This moves the very first call to
BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The
following call tree explains it:
- the new, earlier call is still under BdsEntry(),
- BdsExpandPartitionPartialDevicePathToFull() expects to be called
repeatedly, even with the same set of HD() device paths. This function
implements its own caching for device paths, likely for performance
reasons.
That fits this patch well because whatever device paths we expand under
PlatformBdsPolicyBehavior() can be quickly looked up in
BdsBootDeviceSelect(), so no work (ie.
BdsLibConnectAllDriversToAllControllers()) should be wasted.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
StdLib: Fix pointer arithmetic issues in the strncasecmp function.
The original Linux code tried to be too fancy so the internal pointers got out of sync.
Rewrote the function to at least be more clear.
Regardless, it now works properly.
Fu Siyuan [Thu, 12 Sep 2013 05:26:15 +0000 (05:26 +0000)]
Update the chaining requirements with regards to the Platform Key. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Dong Guo <guo.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14661 6f19259b-4bc3-4df7-8a09-765794883524
Fu Siyuan [Thu, 12 Sep 2013 05:23:28 +0000 (05:23 +0000)]
Add “VendorKeys” variable for indicating out of band key modification. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Dong Guo <guo.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14660 6f19259b-4bc3-4df7-8a09-765794883524
1) The Queue size field in create I/O submission/completion queue cmds is 0-based. the current code is 1-based.
2) a typo on allocated memory page size. it's inconsistent that some places is using 4 pages, but a place is using 6 pages.
3) a typo on PRP/SGL mechanism judgment. should directly use Psdt field rather than Opc field.
4) some platforms may not support UINT64 width access on MMIO register. Fix it to use two 32-bit width access.
Building with the Intel Compiler V11 produces the following error:
StdLib\LibC\Containers\Queues\Fifo.c(223): error #186: pointless comparison of unsigned integer with zero
assert(Count >= 0);
The exception handling support code appears to adjust the stack pointer in the wrong direction.
It decrements the stack pointer by 0x60, but this should be an increment (add) for the
downward-growing stack.
Mars Lin [Thu, 5 Sep 2013 06:12:04 +0000 (06:12 +0000)]
This patch uses dummy routine as NotifyFunction to make sure those 2 APIs provided from library can create event as expected when the caller does not feed in a NotifyFunction. Also, typo is corrected.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mars Lin <Mars_Lin@phoenix.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14631 6f19259b-4bc3-4df7-8a09-765794883524
This updated patch contains the patch:
- Fixed calculation of BaseOfCode in GenFw when the first code section is aligned:
Fixes the calculation of the PE/COFF header attribute .BaseOfCode. when the first ..text. section is aligned.
In the current code base, the alignment of the first code section is not taken into account for the calculation of BaseOfCode.
Roy Franz [Tue, 3 Sep 2013 10:14:02 +0000 (10:14 +0000)]
ArmPkg/CpuPei: Remove unused functions from the driver
The ConfigureMmu() function is unused - the only call to it
is commented out, and the functionality has been moved to
InitMmu() in MemoryInitPeiLib.c.
This change also removes the unused definitions from the file.
Change-Id: Ice795bfee25c403142d0c078533f8a46d04f82e9
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Roy Franz <roy.franz@linaro.org>
Signed-off-by:: Olivier Martin <olivier.martin@arm.com>
Olivier Martin [Tue, 3 Sep 2013 08:52:49 +0000 (08:52 +0000)]
EdkCompatibilityPkg: Fixed build for AArch64
The architecture specific folders must be capitalized (first letter as
a capital letter and the remaining letters in lower case) (INF spec -
2.2.4 Naming Conventions).
The BaseTools only support this requirement for INF revision prior to
0x00010005 (mainly used by EdkCompatibilityPkg, EdkShellPkg, UEFI SCT).
Jordan Justen [Fri, 30 Aug 2013 19:29:09 +0000 (19:29 +0000)]
OvmfPkg NvVarsFileLib: Set NvVars variable after writing vars file
The volatile 'NvVars' variable indicates that the variables do
not need to be loaded from the file again. After we write the
variables out to the file, there is clearly no need to load
them back from the file.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Michael Chang <mchang@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14613 6f19259b-4bc3-4df7-8a09-765794883524
Fu Siyuan [Wed, 28 Aug 2013 09:06:40 +0000 (09:06 +0000)]
1. Change default PCD in SecurityPkg to 4 (DENY_EXECUTE) in DEC file.
2. ASSERT if PCD value is set to 5 (QUERY_USER_ON_SECURITY_VIOLATION).
3. Update override PCD setting from 5 to 4 in platform DSC file. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14607 6f19259b-4bc3-4df7-8a09-765794883524
Girish K S [Tue, 27 Aug 2013 09:17:20 +0000 (09:17 +0000)]
SCR_EL3 is the control register for setting the security state
modified the comment which can mislead.
The "ldr r0, [r1]" is overrided with a immediate "mov ro, #3"
instruction. This mov instruction will over write the contents
of the ro register. So replacing 'mov' by 'orr' instruction would
prevent to override the original value.
This patch assumes mov is the right instruction to be retained
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Girish K S <ks.giri@samsung.com> Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14606 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 26 Aug 2013 02:47:41 +0000 (02:47 +0000)]
MdeModulePkg/DiskIoDxe: fix source/destination pointer of overrun transfer
DiskIoCreateSubtaskList() may split the transfer into three segments:
- a leading segment, called underrun, which is the fractional, trailing
subset of the first underlying block,
- a middle segment, which is an integral multiple of underlying blocks,
- a trailing segment, called overrun, which is the fractional, leading
subset of the last underlying block.
This is an example read from the /EFI/BOOT/BOOTX64.EFI file, on the
RHEL-6.4 installation ISO (debug log enabled with EFI_D_BLKIO). The
underlying block size is 2048 bytes (IDE CD-ROM).
The first line corresponds to the underrun.
The second line corresponds to the overrun.
The third line corresponds to the middle segment.
In decimal:
- task: read 8192 bytes from offset 17920, storing it at BD890018
- underrun:
- read block 8 [16384..18432) into the transfer area,
- copy 512 bytes from offset 1536 of the transfer area to BD890018
(target buffer offset 0, running total: 512)
- middle segment:
- read blocks 9, 10, 11 [18432..24576) into the transfer area,
- copy 6144 bytes from offset 0 of the transfer area to BD890218
(target buffer offset 512, running total: 6656)
- overrun:
- read block 12 [24576..26624) into the transfer area,
- copy 1536 bytes from offset 0 of the transfer area to BD890218 (!!!)
(target buffer offset 512 (!!!), running total 8192)
The values marked with (!!!) constitute the bug --
DiskIoCreateSubtaskList() doesn't take the size of the middle segment into
account when it calculates the destination (for reads) or source (for
writes) pointer for the overrun. This leads to data corruption.
When reading, data is copied form the transfer area to the target buffer
with
calls in DiskIo2OnReadWriteComplete() for nonblocking reads, and in
DiskIo2ReadWriteDisk() for blocking reads. Therefore it's enough to adjust
Subtask->Buffer when it is initialized. (See BD891A18 below.)
The patched call to DiskIoCreateSubtask() is also executed for write
requests. The changed Subtask->Buffer initialization fixes the "overrun
half writes" in DiskIo2ReadWriteDisk() too:
//
// A sub task before this one should be a block read operation, causing
// the WorkingBuffer filled with the entire one block data.
//
CopyMem (Subtask->WorkingBuffer + Subtask->Offset, Subtask->Buffer, Subtask->Length);
This code doubles for underrun and overrun half-writes. The patch doesn't
modify the underrun case.
If we're storing the overrun at the beginning of the pre-read last block
(which we're going to write out as a full block), then
- Subtask->Offset == 0,
- Subtask->Length == OverRun,
- the first byte *not* accessed in the source area is
((Buffer + UnderRunLength) + BufferSize) + OverRun.
Laszlo Ersek [Fri, 23 Aug 2013 18:46:03 +0000 (18:46 +0000)]
OvmfPkg: Virtio: load used ring element strictly after loading used index
Enforce in-order execution of these steps even on not sequentially
consistent architectures, as discussed in [1]. These changes should be
unnecessary on x86 (the only architecture OVMF currently supports), but
they align the OVMF virtio code with the virtio specification and could be
necessary for future OVMF ports.