SVN r14770 ("OvmfPkg/PlatformPei: correctly align emulated NV storage")
made sure the emulated NV storage was allocated with correct alignment.
However, the AllocateRuntimePool() -> AllocateAlignedPages() change
flipped the memory type from EfiRuntimeServicesData to
EfiBootServicesData. This causes variable services to access freed storage
at runtime. It crashes Windows 2008 R2 early at boot, for example.
Keep the alignment, but restore the memory type to EfiRuntimeServicesData,
by calling AllocateAlignedRuntimePages().
These helper functions are implemeted and documented in
"MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.c".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14806 6f19259b-4bc3-4df7-8a09-765794883524
Per 2c4b18e ("MdeModulePkg: Add the alignment check for FTW spare area
address and length, and add the check for PcdFlashNvStorageVariableSize
<= PcdFlashNvStorageFtwSpareSize."), FTWDxe refuses to initialize if
spare space base address or size is not aligned to block size.
Depending on configuration, memory for FTWDxe might be dynamically
allocated in PlatformPei. This patch makes sure that the allocated
memory region is aligned.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14770 6f19259b-4bc3-4df7-8a09-765794883524
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
Since we no longer building page tables in SEC C code, we no
longer need this file.
This reverts commit r14493.
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@14720 6f19259b-4bc3-4df7-8a09-765794883524
Now for X64 we use a VTF0 ResetVector which puts the page
tables in RAM. Therefore SEC no longer needs to do this.
This reverts commit r14494.
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@14719 6f19259b-4bc3-4df7-8a09-765794883524
Since we no longer require flash tables to be stored uncompressed
in the flash image, we can now give extra space to the main/compressed
storage area.
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@14718 6f19259b-4bc3-4df7-8a09-765794883524
This reset vector code will build page tables in RAM at address
0x80000, rather than relying on page tables to be present within
the flash image.
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@14717 6f19259b-4bc3-4df7-8a09-765794883524
In UEFI X64 we use other mechanisms to disable caching.
(CD/NW in CR0 and MTRRs.)
This fixes a slow boot issue with SVM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14716 6f19259b-4bc3-4df7-8a09-765794883524
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
(1) OVMF depends on
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
unconditionally.
(2) When OVMF is built with -D SECURE_BOOT_ENABLE, then
SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
is injected into SecurityStubDxe above.
(3) SVN r14687 ("Add TPM2 implementation.") has made
DxeImageVerificationLib dependent on TpmMeasurementLib.
Currently the last link of the
OVMF -> SecurityStubDxe -> DxeImageVerificationLib -> TpmMeasurementLib
dependency chain is unresolved:
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.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14690 6f19259b-4bc3-4df7-8a09-765794883524
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
This will allow us to identify those UEFI boot options (while keeping
their relative order) that have *not* been selected by fw_cfg.
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@14667 6f19259b-4bc3-4df7-8a09-765794883524
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.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
[jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14666 6f19259b-4bc3-4df7-8a09-765794883524
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:
BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
This should be fine, for two reasons:
- 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
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
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
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.
[1] http://lists.linuxfoundation.org/pipermail/virtualization/2013-June/024547.html
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14601 6f19259b-4bc3-4df7-8a09-765794883524
Previously OVMF included the older EFI shell binary when building.
Now we will build and use the UEFI shell (ShellPkg) instead.
v2:
* Don't bother building UEFI shell when USE_OLD_SHELL is defined
* Fix errors in OvmfPkgIa32X64.fdf
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14600 6f19259b-4bc3-4df7-8a09-765794883524
When enrolling the certificate from a file, the suffix check function
check the last 4 characters to filter out non-DER files. However,
if the length of the file name is less than 4, the address prior to
the file name will be accessed while it shouldn't. This commit checks
the length of the file name to avoid illegal access.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14556 6f19259b-4bc3-4df7-8a09-765794883524
In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services()
expect that whoever allocates the EFI memmap allocates it in Loader Data
type memory. Linux's own exit_boot()-->low_alloc() complies, but
SetupLinuxMemmap() in LoadLinuxLib doesn't.
The memory type discrepancy leads to efi_memblock_x86_reserve_range() and
efi_reserve_boot_services() both trying to reserve the range backing the
memmap, resulting in memmap entry truncation in
efi_reserve_boot_services().
This fix also makes this allocation consistent with all other persistent
allocations in "OvmfPkg/Library/LoadLinuxLib/Linux.c".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
This is based on MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c.
Previously we would run using page tables built into the
firmware device.
If a flash memory is available, it is unsafe for the page
tables to be stored in memory since the processor may try
to write to the page table data structures.
Additionally, when KVM ROM support is enabled for the
firmware device, then PEI fails to boot when the page
tables are in the firmware device.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14494 6f19259b-4bc3-4df7-8a09-765794883524
When the PM base address was moved from 0x400 to 0xb000, this
code was missed. This prevented shutdown's via the UEFI system
call from working. (For example, at the EFI shell prompt: reset -s)
We now use gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
which is currently set at 0xb000.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14492 6f19259b-4bc3-4df7-8a09-765794883524
r14252 causes OVMF to crash if SECURE_BOOT_ENABLE is set,
because PcdMaxVariableSize is set to a larger value than
required. In other platforms, 0x2000 seems to be sufficient.
Reported-by: Gary Ching-Pang Lin <glin@suse.com>
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@14423 6f19259b-4bc3-4df7-8a09-765794883524
Also summarize the resultant NIC driver options in the README file.
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: Stefan Hajnoczi <stefanha@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14421 6f19259b-4bc3-4df7-8a09-765794883524
These changes were needed in addition to the silence.patch
that Laszlo posted on May 28.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14420 6f19259b-4bc3-4df7-8a09-765794883524
These were found with the gcc-4.4 option "-Wconversion" after Jordan
reported the build failure under Visual Studio. The patch was originally
posted to edk2-devel as "silence.patch":
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2804/focus=2972
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: Stefan Hajnoczi <stefanha@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14419 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg's file-based NvVar storage is read back as follows at boot (all
paths under OvmfPkg/Library/):
PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c]
PlatformBdsRestoreNvVarsFromHardDisk()
VisitAllInstancesOfProtocol
for each simple file system:
VisitingFileSystemInstance()
ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c]
LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c]
ReadNvVarsFile()
+-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c]
| SerializeVariablesIterateInstanceVariables()
| +-------------> IterateVariablesInBuffer()
| | for each loaded / deserialized variable:
| +-|-----------------> IterateVariablesCallbackSetSystemVariable()
| | | gRT->SetVariable()
| | |
| | IterateVariablesInBuffer() stops processing variables as soon as the
| | first error is encountered from the callback function.
| |
| | In this case the callback function is
| IterateVariablesCallbackSetSystemVariable(), selected by
SerializeVariablesSetSerializedVariables().
The result is that no NvVar is restored from the file after the first
gRT->SetVariable() failure.
On my system such a failure
- never happens in an OVMF build with secure boot disabled,
- happens *immediately* with SECURE_BOOT_ENABLE, because the first
variable to restore is "AuthVarKeyDatabase".
"AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
attribute set. Since the loop tries to restore it before any keys (PK, KEK
etc) are enrolled, gRT->SetVariable() rejects it with
EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates
immediately, and we never reach non-authenticated variables such as
Boot#### and BootOrder.
Until work on KVM-compatible flash emulation converges between qemu and
OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking
EFI_SECURITY_VIOLATION in the callback:
- authenticated variables continue to be rejected same as before, but
- at least we allow the loop to progress and restore non-authenticated
variables, for example boot options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
DHCP, PXE, and StdLib socket apps are enabled in OVMF by the sum of:
(a) a UEFI NIC driver,
(b) the generic network stack.
The only choice for (a) used to be the proprietary Intel E1000 driver,
which is cumbersome to obtain and enable.
The iPXE UEFI NIC drivers packaged with qemu-1.5 cover (a) for each NIC
type supported by qemu, and are easy to obtain & configure, even for
earlier qemu versions. Therefore enable (b) per default as well.
This doesn't take up much space; the binaries (b) adds to the firmware
don't seem to need -D FD_SIZE_2MB.
Intel's e1000 driver remains an option, requested by the -D E1000_ENABLE
build flag.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14366 6f19259b-4bc3-4df7-8a09-765794883524
The descriptor table (also known as "queue") consists of descriptors. (The
corresponding type in the code is VRING_DESC.)
An individual descriptor describes a contiguous buffer, to be transferred
uni-directionally between host and guest.
Several descriptors in the descriptor table can be linked into a
descriptor chain, specifying a bi-directional scatter-gather transfer
between host and guest. Such a descriptor chain is also known as "virtio
request".
(The descriptor table can host sereval descriptor chains (in-flight virtio
requests) in parallel, but the OVMF driver supports at most one chain, at
any point in time.)
The first descriptor in any descriptor chain is called "head descriptor".
In order to submit a number of parallel requests (= a set of independent
descriptor chains) from the guest to the host, the guest must put *only*
the head descriptor of each separate chain onto the Available Ring.
VirtioLib currently places the head of its one descriptor chain onto the
Available Ring repeatedly, once for each single (head *or* dependent)
descriptor in said descriptor chain. If the descriptor chain comprises N
descriptors, this error amounts to submitting the same entire chain N
times in parallel.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Ptr to head --/ Desc#1 (next in same chain)
... / ...
Ptr to head / Desc#(N-1) (last in same chain)
Anatomy of a single virtio-blk READ request (a descriptor chain with three
descriptors):
virtio-blk request header, prepared by guest:
VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232
payload to be filled in by host:
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233
host status, to be filled in by host:
VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234
Processing on the host side -- the descriptor chain is processed three
times in parallel (its head is available to virtqueue_pop() thrice); the
same chain is submitted/collected separately to/from AIO three times:
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1
virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
virtio_blk_rw_complete req REQ#1 ret 0
virtio_blk_req_complete req REQ#1 status 0
virtio_blk_rw_complete req REQ#2 ret 0
virtio_blk_req_complete req REQ#2 status 0
On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to
simultaneous DMA transfers targeting the same RAM area. Even though the
source of each transfer is identical, the data is corrupted in the
destination buffer -- the CRC32 calculated over the buffer varies, even
though the origin of the transfers is the same, never rewritten LBA.
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D
The problem is invisible on my HP Z400 workstation.
Fix the request submission by:
- building the only one descriptor chain supported by VirtioLib always at
the beginning of the descriptor table,
- ensuring the head descriptor of this chain is put on the Available Ring
only once,
- requesting the virtio spec's language to be cleaned up
<http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Desc#1 (next in same chain)
...
Desc#(N-1) (last in same chain)
VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1
VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07
(The Crc32 was double-checked with edk2's and Linux's guest IDE driver.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
The README is rather extended than trimmed, so that users grepping for the
file name have a pointer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14243 6f19259b-4bc3-4df7-8a09-765794883524
Also, add a small delay after the 0xCF9 hard reset request -- on qemu/kvm the
port access is translated to the qemu-internal system reset request by the CPU
thread, and it might progress some more before the IO thread acts upon the
system reset request.
MicroSecondDelay() is implemented by OvmfPkg's own AcpiTimerLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14158 6f19259b-4bc3-4df7-8a09-765794883524
The reset requested via the keyboard controller (port 0x64) is actually a
soft reset, but qemu has supported it since forever (plus qemu has not
distinguished between hard reset and soft reset, although this is changing
now). Therefore leave the current IoWrite() in place for compatibility.
On qemu versions with commit 1ec4ba74 ("PIIX3: reset the VM when the Reset
Control Register's RCPU bit gets set"), use the PIIX3 RCR as first choice.
In the future qemu will act differently on soft vs. hard reset requests,
and we should honor that in ResetCold().
Writing to ioport 0xCF9 on qemu builds prior to commit 1ec4ba74 should
have no effect. Access to the PCI host config register went through
several implementations in qemu. Commit 9f6f0423 ("pci_host: rewrite
using rwhandler") seems safe, both before and after.
Commit d0ed8076 ("pci_host: convert conf index and data ports to memory
API") inadvertently dropped the alignment/size check, causing a boot
regression on NetBSD. It was fixed about six months later in commit
cdde6ffc, which is current. Translating that to qemu releases, the bug
was visible from v1.0 to v1.1.0.
On physical hardware cycling between reset methods is sometimes necessary
<http://mjg59.dreamwidth.org/3561.html>. On qemu the port access should
trap immediately.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14157 6f19259b-4bc3-4df7-8a09-765794883524
The value to be written corresponds to hard reset, which is what the ACPI
spec prescribes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14156 6f19259b-4bc3-4df7-8a09-765794883524
This conversion cannot be split very well into smaller patches. Comparing
version 1 and version 2 (modulo the header fields):
> --- EFI_ACPI_1_0_FIXED_ACPI_DESCRIPTION_TABLE
> +++ EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE
> @@ -1,14 +1,14 @@
> EFI_ACPI_DESCRIPTION_HEADER Header;
> UINT32 FirmwareCtrl;
> UINT32 Dsdt;
> - UINT8 IntModel;
> - UINT8 Reserved1;
> + UINT8 Reserved0;
> + UINT8 PreferredPmProfile;
The INT_MODEL field was present in ACPI 1.0, but eliminated in 2.0.
According to the spec, "platforms should set this field to zero but field
values of one are also allowed to maintain compatibility with ACPI 1.0".
We're setting it to zero.
About Preferred_PM_Profile (taking the place of an 1.0 reserved field),
the specification says:
This field is set by the OEM to convey the preferred power management
profile to OSPM. OSPM can use this field to set default power management
policy parameters during OS installation.
>From <MdePkg/Include/IndustryStandard/Acpi20.h>:
#define EFI_ACPI_2_0_PM_PROFILE_UNSPECIFIED 0
#define EFI_ACPI_2_0_PM_PROFILE_DESKTOP 1
#define EFI_ACPI_2_0_PM_PROFILE_MOBILE 2
#define EFI_ACPI_2_0_PM_PROFILE_WORKSTATION 3
#define EFI_ACPI_2_0_PM_PROFILE_ENTERPRISE_SERVER 4
#define EFI_ACPI_2_0_PM_PROFILE_SOHO_SERVER 5
#define EFI_ACPI_2_0_PM_PROFILE_APPLIANCE_PC 6
For a virtual machine, "unspecified" is the best choice.
> UINT16 SciInt;
> UINT32 SmiCmd;
> UINT8 AcpiEnable;
> UINT8 AcpiDisable;
> UINT8 S4BiosReq;
> - UINT8 Reserved2;
> + UINT8 PstateCnt;
We've been already treating this field as PSTATE_CNT. No change in value.
> UINT32 Pm1aEvtBlk;
> UINT32 Pm1bEvtBlk;
> UINT32 Pm1aCntBlk;
> @@ -20,11 +20,11 @@
> UINT8 Pm1EvtLen;
> UINT8 Pm1CntLen;
> UINT8 Pm2CntLen;
> - UINT8 PmTmLen;
> + UINT8 PmTmrLen;
(Field renaming artifact.)
> UINT8 Gpe0BlkLen;
> UINT8 Gpe1BlkLen;
> UINT8 Gpe1Base;
> - UINT8 Reserved3;
> + UINT8 CstCnt;
We've been already treating this field as CST_CNT. No change in value.
> UINT16 PLvl2Lat;
> UINT16 PLvl3Lat;
> UINT16 FlushSize;
> @@ -34,7 +34,19 @@
> UINT8 DayAlrm;
> UINT8 MonAlrm;
> UINT8 Century;
> - UINT8 Reserved4;
> - UINT8 Reserved5;
> - UINT8 Reserved6;
> + UINT16 IaPcBootArch;
> + UINT8 Reserved1;
The first two octets are now merged into a 16-bit short; otherwise we've
been treating those as boot architecture flags already (see SVN rev
13615). No change in value.
> UINT32 Flags;
The fixed feature flags are not modified, only the macro names (expanding
to identical values) are updated to ACPI 2.0.
The following fields are all new in ACPI 2.0:
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE ResetReg;
> + UINT8 ResetValue;
We don't claim support for the reset register yet.
> + UINT8 Reserved2[3];
> + UINT64 XFirmwareCtrl;
> + UINT64 XDsdt;
The 64-bit physical addresses for the FACS and the DSDT are automatically
filled at installation time, see AddTableToList() and DeleteTable() in
"MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c".
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aEvtBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bEvtBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1aCntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm1bCntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPm2CntBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XPmTmrBlk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe0Blk;
> + EFI_ACPI_2_0_GENERIC_ADDRESS_STRUCTURE XGpe1Blk;
We specify the extended addresses for the required and supported PM1a
Event & Control, PM Timer, and GPE0 Register Blocks, and zero the rest, in
accordance with the ACPI 1.0 fields.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14155 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we're going to specify Extended Addresses of register
blocks in Generic Address Structure format. The GAS is easy to fill if we
want to posit either "unsupported" (all zero) or a given address in a
specific address space. However deriving "unsupported" just from a macro
expanding to zero is unwieldy, so let's avoid the need.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14154 6f19259b-4bc3-4df7-8a09-765794883524
Soon we're going to specify Extended Addresses of register blocks in
Generic Address Structure format. The GAS is easy to fill if we want to
posit either "unsupported" (all zero) or a given address in a specific
address space. However deriving "unsupported" just from a macro expanding
to zero is unwieldy, so let's avoid the need.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14153 6f19259b-4bc3-4df7-8a09-765794883524
Soon we're going to specify Extended Addresses of register blocks in
Generic Address Structure format. The GAS is easy to fill if we want to
posit either "unsupported" (all zero) or a given address in a specific
address space. However deriving "unsupported" just from a macro expanding
to zero is unwieldy, so let's avoid the need.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14152 6f19259b-4bc3-4df7-8a09-765794883524
With reference to
<http://sourceforge.net/mailarchive/message.php?msg_id=30359322>:
"MEMFD is built so MAINFV's contents will be relocated during the build to
address 0x800000", and it "is a firmware volume with most OVMF code/data
uncompressed. [...] Increasing its size has a little impact on the size of
the resulting firmware image since the blank part of the firmware volume
will compress well."
Let's increase the size to 8MB, since the current limit can get in the way
(for example when building-in the Intel3.5 drivers for e1000 with
-D FD_SIZE_2MB -D NETWORK_ENABLE -D SECURE_BOOT_ENABLE).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14133 6f19259b-4bc3-4df7-8a09-765794883524
Usage of the EFI entry point was made feasible in the kernel
x64 boot protocol 2.12 where a 32-bit & 64-bit entry point
became well defined.
http://git.kernel.org/linus/09c205af
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14132 6f19259b-4bc3-4df7-8a09-765794883524
This should be more compatible with AML parsers in practice
since older versions of ACPICA's OS support would not accept
the previous OVMF format (despite being spec compliant).
(For example, on OpenBSD 5.2 it caused a kernel crash)
ACPICA has fixed this issue in:
https://github.com/otcshare/acpica/commit/5869690a
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14130 6f19259b-4bc3-4df7-8a09-765794883524
We cannot specify a pin-GSI connection for the SCI directly in the _PRT
because that implies ActiveLow polarity, clashing with both qemu and the
MADT we prepare.
With this patch the RHEL-6 guest logs the following:
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
The patch amends svn rev 13625. Testing it in a RHEL-6 guest, the problems
described in
<http://sourceforge.net/mailarchive/message.php?msg_id=29660862> do not
reappear.
The code is derived from Paolo Bonzini's patch (originally appearing as
SeaBIOS commit f64a472a, "acpi: reintroduce LNKS"). Said original patch is
copyrighted by Red Hat (our common employer), and it has been relicensed
<http://sourceforge.net/mailarchive/message.php?msg_id=30393854> to form
the basis of this derived patch for edk2. The latter is therefore
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14111 6f19259b-4bc3-4df7-8a09-765794883524
Previously for IA32, we would only try to run qemu. Newer releases
of QEMU now have renamed the x86 qemu to qemu-system-i386.
Now, we search for:
1. qemu-system-i386
2. qemu-system-x86_64
3. qemu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14101 6f19259b-4bc3-4df7-8a09-765794883524
The Xcode assembler is much pickier than GCC. Also the 64-bit
linker is not a fan of relocations so it is better to us IP
relative code, but at least it removes a relocation entry.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
[jordan.l.justen@intel.com: use .byte for retfq rather than lret]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14055 6f19259b-4bc3-4df7-8a09-765794883524
We're supposed to zero everything in the kernel bootparams that we don't
explicitly initialise, other than the setup_header from 0x1f1 onwards
for a precisely defined length, which is copied from the bzImage.
We're *not* supposed to just pass the garbage that we happened to find
in the bzImage file surrounding the setup_header.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14052 6f19259b-4bc3-4df7-8a09-765794883524
Boot protocol 2.05 just means that the relocatable_kernel field is present
in the header. We should actually check that it's *set*.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14051 6f19259b-4bc3-4df7-8a09-765794883524
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
Move these states from the DSDT to the SSDT. Override the default
configuration if the host has the following qemu commit:
commit 459ae5ea5ad682c2b3220beb244d4102c1a4e332
Author: Gleb Natapov <gleb@redhat.com>
Date: Mon Jun 4 14:31:55 2012 +0300
Add PIIX4 properties to control PM system states.
This patch adds two things. First it allows QEMU to distinguish
between regular powerdown and S4 powerdown. Later separate QMP
notification will be added for S4 powerdown. Second it allows
S3/S4 states to be disabled from QEMU command line. Some guests
known to be broken with regards to power management, but allow to
use it anyway. Using new properties management will be able to
disable S3/S4 for such guests.
Supported system state are passed to a firmware using new fw_cfg
file. The file contains 6 byte array. Each byte represents one
system state. If byte at offset X has its MSB set it means that
system state X is supported and to enter it guest should use the
value from lowest 3 bits.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.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>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14003 6f19259b-4bc3-4df7-8a09-765794883524
The ACPI 5.0 specification says:
7.3.4.4 System \_S3 State
[...]
* Dynamic RAM context is maintained.
[...]
This corresponds to the following in the PIIX4 spec:
PMCNTRL -- POWER MANAGEMENT CONTROL REGISTER (IO)
[...]
Bits[12:10] Suspend Type
[...]
001 STR (Suspend To RAM)
Also, this (ie. decimal 1) is the suspend type value that qemu recognizes
as an S3 (suspend to ram) request.
Only the value for PM1a_CNT.SLP_TYP is set (PM1b_CNT.SLP_TYP is left at
zero), since in OVMF we don't report the optional PM1b_EVT_BLK register
block to OSPM. (PM1b_EVT_BLK is defined as 0 in "Platform.h"; see "4.8.1.1
PM1 Event Registers" in the ACPI 5.0 specification.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14002 6f19259b-4bc3-4df7-8a09-765794883524
The ACPI 5.0 specification says:
7.3.4.5 System \_S4 State
[...]
* DRAM context is not maintained.
[...]
This corresponds to the following in the PIIX4 spec:
PMCNTRL -- POWER MANAGEMENT CONTROL REGISTER (IO)
[...]
Bits[12:10] Suspend Type
[...]
010 POSCL (Powered On Suspend, Context Lost)
Also, this (ie. decimal 2) is the default suspend type value that qemu
recognizes as an S4 (suspend to disk) request.
Only the value for PM1a_CNT.SLP_TYP is corrected (PM1b_CNT.SLP_TYP is left
at zero), since in OVMF we don't report the optional PM1b_EVT_BLK register
block to OSPM. (PM1b_EVT_BLK is defined as 0 in "Platform.h"; see "4.8.1.1
PM1 Event Registers" in the ACPI 5.0 specification.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14001 6f19259b-4bc3-4df7-8a09-765794883524
The qemu standard vga has a MMIO bar in qemu 1.3+.
Use it if available.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13969 6f19259b-4bc3-4df7-8a09-765794883524
Move to a table-driven hardware detection. Add a table with PCI IDs,
card name and variant enum. Use the table for hardware detection and
initialization. Rename Cirrus-specific data and code to carry "cirrus"
in the name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13967 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU's -kernel parameter was used, then download the
kernel from the FwCfg interface, and launch it. (See -kernel,
-initrd, -append) The application uses the LoadLinuxLib to boot
the kernel image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13923 6f19259b-4bc3-4df7-8a09-765794883524
This code is based on efilinux's bzimage support.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Matt Fleming <matt.fleming@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13922 6f19259b-4bc3-4df7-8a09-765794883524
This file is from the efilinux project where it resides
under the path loaders/bzimage/bzimage.h.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Matt Fleming <matt.fleming@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13920 6f19259b-4bc3-4df7-8a09-765794883524
Structures should not be directly assigned in EDK II
code, since this leads to different behaviours on various
compilers.
Instead, use ZeroMem to zero out the structures.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13878 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Wei Liu
Olivier Martin
Matt Fleming
Jordan Justen
Fu Siyuan
Ruiyu Ni
Gary Ching-Pang Lin
Eric Dong
Star Zeng
jljusten
andrewfish