The logic we have in place for i440fx does not work reliably on q35. For
example, if the guest has 2GB of RAM, we allow the PCI root bridge driver
to allocate the legacy video RAM BAR from the [2048 MB, 2816 MB] range,
which falls strictly outside of the Q35 PCI host MMIO aperture that QEMU
configures, and advertizes in ACPI.
In turn, PCI BARs that exist outside of the PCI host aperture that is
exposed in ACPI break Windows guests.
Allocating PCI MMIO resources at or above 3GB on Q35 ensures that we stay
within QEMU's aperture. (See the "w32.begin" assignments in
"hw/pci-host/q35.c".) Furthermore, in pc_q35_init() (file
"hw/i386/pc_q35.c"), QEMU ensures that the low RAM never "leaks" above
3GB.
The i440fx logic is left unchanged.
The Windows guest malfunction on Q35 was reported by Jon Panozzo of Lime
Technology, Inc.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jon Panozzo <jonp@lime-technology.com>
Cc: "Gabriel L. Somlo" <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Jonathan Panozzo <jonp@lime-technology.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18393 6f19259b-4bc3-4df7-8a09-765794883524
Bruce Cran reported the following issue:
With iasl version 20150410-64 building OvmfX64 (using OvmfPkg/build.sh
-a X64 -t GCC49 -b RELEASE) results in a couple of warnings about
methods that should be serialized:
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
95: Method (_CRS, 0) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
.../OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iiii
235: Method (PCRS, 1, NotSerialized) {
Remark 2120 - Control Method should be made Serialized ^ (due to
creation of named objects within)
The ACPI 6.0 spec justifies the above warnings in "19.6.82 Method (Declare
Control Method)":
[...] The serialize rule can be used to prevent reentering of a method.
This is especially useful if the method creates namespace objects.
Without the serialize rule, the reentering of a method will fail when it
attempts to create the same namespace object. [...]
Cc: Bruce Cran <bruce@cran.org.uk>
Reported-by: Bruce Cran <bruce@cran.org.uk>
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@18392 6f19259b-4bc3-4df7-8a09-765794883524
We have an old bug in BootModeInitialization(): firmware is supposed to
clear the CMOS register 0xF after reading it for the last time. QEMU only
sets this register to 0xFE in "hw/timer/mc146818rtc.c", function
rtc_notify_suspend(), and never clears it. However, SeaBIOS does clear it
in "src/post.c" and "src/resume.c", so let's follow suit.
We've never noticed this until now because the register gets mysteriously
cleared on non-resume reboots when OVMF runs on qemu-system-x86_64. But on
qemu-system-i386, this bug breaks a (suspend, resume, reboot) triplet:
after the last step OVMF thinks it's resuming because when it actually
resumed (in the middle step), it failed to clear the register.
BootModeInitialization() is the perfect function to clear the register,
right after setting mBootMode: the function is executed on both normal
boot and on S3 resume; it succeeds DebugDumpCmos() -- so the dump is not
affected by this patch --; and everything that relies on S3 vs. normal
boot after we clear the register uses mBootMode anyway.
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@18391 6f19259b-4bc3-4df7-8a09-765794883524
SVN rev 18166 ("MdeModulePkg DxeIpl: Add stack NX support") enables
platforms to request non-executable stack for the DXE phase, by setting
PcdSetNxForStack to TRUE.
The PCD defaults to FALSE, because:
(a) A non-executable DXE stack is a new feature and causes changes in
behavior. Some platform could rely on executing code from the stack.
(b) The code enabling NX in the DXE IPL PEIM enforces the
PcdSetNxForStack ==> PcdDxeIplBuildPageTables
implication for "64-bit PEI + 64-bit DXE" platforms, with a new
ASSERT(). Some platform might not comply with this requirement
immediately.
Regarding (a), in none of the OVMF builds do we try to execute code from
the stack.
Regarding (b):
- In the OvmfPkgX64.dsc build (which is where (b) applies) we simply
inherit the PcdDxeIplBuildPageTables|TRUE default from
"MdeModulePkg/MdeModulePkg.dec". Therefore we can set PcdSetNxForStack
to TRUE.
- In OvmfPkgIa32X64.dsc, page tables are built by default for DXE. Hence
we can set PcdSetNxForStack to TRUE.
- In OvmfPkgIa32.dsc, page tables used not to be necessary until now.
After we set PcdSetNxForStack to TRUE in this patch, the DXE IPL will
construct page tables even when it is built as part of OvmfPkgIa32.dsc,
provided the (virtual) hardware supports both PAE mode and the XD bit.
Should this setting cause problems in a GPU (or other device) passthru
scenario, with a UEFI_DRIVER in the PCI option rom attempting to execute
code from the stack, the feature can be dynamically disabled on the QEMU
command line, with "-cpu <MODEL>,-nx".
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: "Zeng, Star" <star.zeng@intel.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18360 6f19259b-4bc3-4df7-8a09-765794883524
Since SVN r18316 / git 5ca29abe52, the HTTP driver needs the HTTP
utilities driver to parse the headers of HTTP requests. Add the driver
into OVMF so that the HTTP driver can work properly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
Since Variable driver has been updated to consume the separated VarCheckLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18281 6f19259b-4bc3-4df7-8a09-765794883524
This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE.
When HttpBoot is enabled, a new Network boot option will show in the
boot manager menu with the device path like this:
PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri()
It works like the PXE one but fetches the NBP from the given http
url instead of the tftp service.
A simple testing environment can be set up with the QEMU tap network
and dnsmasq + lighttpd.
Here is the example of the dnsmasq config:
interface=<tap interface>
dhcp-range=192.168.111.100,192.168.111.120,12h
dhcp-option=60,"HTTPClient"
dhcp-boot="http://<tap ip>/<efi file>"
It's similar to the PXE server settings except the tftp function is
disabled, the option 60 must be "HTTPClient", and the boot uri is a
http url.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-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@18258 6f19259b-4bc3-4df7-8a09-765794883524
The Clang assembler for AArch64 chokes on the value 0XEA1 since it
expects the 0x prefix to use a lower case x.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18204 6f19259b-4bc3-4df7-8a09-765794883524
Also set the DocRev field the way QEMU exposes it, because
MdeModulePkg/Universal/SmbiosDxe lets us control that field too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18182 6f19259b-4bc3-4df7-8a09-765794883524
At this point all platforms that use OvmfPkg/SmbiosPlatformDxe in edk2,
namely ArmVirtQemu.dsc and OvmfPkg*.dsc, have been migrated to
SmbiosVersionLib. Therefore SmbiosPlatformDxe itself can forego verifying
QEMU's SMBIOS entry point; if SmbiosVersionLib's validation was
successful, it should just rely on that.
(Note that SmbiosPlatformDxe has a depex on EFI_SMBIOS_PROTOCOL, installed
by SmbiosDxe, containing SmbiosVersionLib, therefore the set/get order of
PcdQemuSmbiosValidated is ensured.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18180 6f19259b-4bc3-4df7-8a09-765794883524
This dynamic PCD will enable a small code de-duplication between
OvmfPkg/SmbiosPlatformDxe and OvmfPkg/Library/SmbiosVersionLib. Since both
of those are also used in ArmVirtQemu.dsc, and we should avoid
cross-package commits when possible, this patch declares
PcdQemuSmbiosValidated first, and sets defaults for it in the OvmfPkg DSC
files.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18178 6f19259b-4bc3-4df7-8a09-765794883524
This patch de-duplicates the logic added in commit
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically
(git 37baf06b, SVN r17676) by hooking DetectSmbiosVersionLib into
SmbiosDxe.
Although said commit was supposed to work with SMBIOS 3.0 payloads from
QEMU, in practice that never worked, because the size / signature checks
in SmbiosVersionInitialization() would always fail, due to the SMBIOS 3.0
entry point being structurally different. Therefore this patch doesn't
regress OvmfPkg.
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18175 6f19259b-4bc3-4df7-8a09-765794883524
Introduce a minimal library instance for fetching and validating the
SMBIOS entry point structure exposed by QEMU over fw_cfg. This library is
meant to be hooked into MdeModulePkg/Universal/SmbiosDxe by platform DSC
files, so that the library can set the PCD(s) that SmbiosDxe consumes at
the right moment.
At the moment only SMBIOS 2.x entry points are recognized.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18174 6f19259b-4bc3-4df7-8a09-765794883524
The LineNumber parameter of the DebugAssert() function has type UINTN.
DebugAssert() passes it to AsciiSPrint() with the %d conversion specifier
at the moment, but %d would require an INT32 argument.
Fix this by casting LineNumber to UINT64, also employing the matching
decimal conversion specifier, %Lu.
(Another possibility would be to cast LineNumber to INT32, but a
UINTN->INT32 cast is not value preserving, generally speaking.)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Scott Duplichan <scott@notabs.org>
Reported-by: Scott Duplichan <scott@notabs.org>
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@18173 6f19259b-4bc3-4df7-8a09-765794883524
The Xen code in SmbiosPlatformDxe is centered on the informational HOB
with GUID gEfiXenInfoGuid, and the address constants
XEN_SMBIOS_PHYSICAL_ADDRESS=0x000EB000,
XEN_SMBIOS_PHYSICAL_END=0x000F0000.
This Xen hand-off mechanism is specific to the IA32 and X64 architectures,
and it is very unlikely that a future ARM / AARCH64 implementation would
follow it. Therefore, sequester the IA32 / X64 specific code from the rest
of the source, by renaming "Xen.c" to "X86Xen.c", and adding a
GetXenSmbiosTables() stub function in "ArmXen.c" that returns NULL.
(Those file names are inspired by
"OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c".)
The call site in SmbiosTablePublishEntry() [SmbiosPlatformDxe.c] is aware
that a NULL return value means "Xen SMBIOS tables not found", and will
continue to the QEMU tables (for which the retrieval mechanism is shared
by x86 and Arm).
This change enables SmbiosPlatformDxe for ARM architectures; update the
VALID_ARCHITECTURES comment accordingly.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
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@18040 6f19259b-4bc3-4df7-8a09-765794883524
This function is only called from Xen.c, so it should be defined in Xen.c
and have internal linkage (ie. STATIC).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18039 6f19259b-4bc3-4df7-8a09-765794883524
At this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL
member functions; simplify the code by dropping this protocol interface.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18038 6f19259b-4bc3-4df7-8a09-765794883524
Currently we have the following call chain in OVMF:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The bottom of this call chain was introduced in git commit 5a217a06 (SVN
r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That
patch was necessary because there was no other way, due to GenericBdsLib
calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary
steps in the right order:
- save S3 system information,
- save a final (well, only) boot script opcode,
- signal DxeSmmReadyToLock, closing the boot script, and locking down
LockBox and SMM.
The GenericBdsLib bug has been fixed in the previous patch -- the call in
BdsLibBootViaBootOption() has been eliminated.
Therefore, hoist the SaveS3BootScript() code, and call, from
OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
<---
SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,
not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without
upsetting the relative order of the steps.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18037 6f19259b-4bc3-4df7-8a09-765794883524
(Paraphrasing git commit 9cd7d3c5 / SVN r17713:)
Currently, OvmfPkg fails to signal the End-of-Dxe event group when
entering the BDS phase, which results in some loss of functionality, eg.
variable reclaim in the variable driver, and the memory region splitting
in the DXE core that belongs to the properties table feature specified in
UEFI-2.5.
As discussed on the edk2-devel mailing list here:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
it is up to the platform BDS to signal End-of-Dxe, since there may be
platform specific ordering constraints with respect to the signalling of
the event that are difficult to honor at the generic level.
(OvmfPkg specifics:)
(1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration
completes. According to the previous patch, that would trigger
OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of
action happened:
- PCI enumeration completes
- ACPI tables are installed by OvmfPkg/AcpiPlatformDxe
- the FACS table becomes available
Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table
is available, we must delay the End-of-Dxe signal until after PCI
enumeration completes (ie. root bridges are connected).
(2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c].
After the patch, we enter S3Ready() earlier than that, by signaling
End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of
this new call is correct as well, and the original call (that now
becomes the chronologically second call) becomes a no-op: S3Ready() is
protected against 2nd and later entries.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18035 6f19259b-4bc3-4df7-8a09-765794883524
Call S3Ready() whenever the first of the following occurs:
- a driver signals End-of-Dxe,
- a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save().
S3Ready() already contains a static, function scope "latch" that causes it
to exit early when called for the second time or later.
(At the moment, the only platform in the edk2 tree that includes this
driver is OvmfPkg. That platform does not signal End-of-Dxe (yet).)
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
Suggested-by: Yao Jiewen <jiewen.yao@intel.com>
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18034 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18033 6f19259b-4bc3-4df7-8a09-765794883524
The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for
a device that is plugged into the main PCI root bus, is:
/pci@i0cf8/...
Whereas the same device plugged into the N'th extra root bus results in:
/pci@i0cf8,N/pci-bridge@0/...
(N is in hex.)
Extend TranslatePciOfwNodes() so that it not assume a single PCI root;
instead it parse the extra root bus serial number if present, and resolve
it in the translation to the UEFI devpath fragment.
Note that the "pci-bridge@0" node is a characteristic of QEMU's PXB
device. It reflects the actual emulated PCI hierarchy. We don't parse it
specifically in this patch, because it is automatically handled by the
bridge sequence translator added recently in SVN rev 17385 (git commit
feca17fa4b) -- "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of
PCI bridges".
The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW
device paths that we wish to recognize under this new scheme comprise 5
nodes. The initial "extra root bus" OFW fragment, visible at the top,
takes up 2 nodes, after which the longest device-specific patterns (IDE
disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17965 6f19259b-4bc3-4df7-8a09-765794883524
SeaBIOS requires the OpenFirmware device paths exported in the "bootorder"
fw-cfg file to refer to extra (PXB) root buses by their relative positions
(in increasing bus number order) rather than by actual bus numbers.
However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID)
device path nodes for extra PCI root buses with UID=bus_nr, not position.
(These ACPI devpath UID values must, and do, match the UID values exposed
in QEMU's ACPI payload, generated for PXB root buses.)
Therefore the boot order matching logic will have to map extra root bus
positions to bus numbers. Add a small group of utility functions to help
with that.
Cc: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17964 6f19259b-4bc3-4df7-8a09-765794883524
QEMU provides an fw_cfg file called "etc/extra-pci-roots", containing a
little-endian UINT64 value that exposes the number of extra root buses. We
can use this value to terminate the scan as soon as we find the last extra
root bus.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17963 6f19259b-4bc3-4df7-8a09-765794883524
In this patch we assume that root bus number 0 is always there (same as
before), and scan the rest of the extra root buses, up to and including
255. When an extra root bus is found, we install the PCI root bridge IO
protocol for the previous root bus (which might be bus 0 or just the
previous extra root bus).
The root bridge protocol created thus will report the available bus number
range
[own bus number, next extra root bus number - 1]
The LHS of this interval will be used for the root bus's own number, and
the rest of the interval (which might encompass 0 additional elements too)
can be used by the PCI bus driver to assign subordinate bus numbers from.
(Subordinate buses are provided by PCI bridges that hang off the root bus
in question.)
For MMIO and IO space allocation, all the root buses share the original
[0x8000_0000, 0xFFFF_FFFF] and [0x0, 0xFFFF] ranges, respectively.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17962 6f19259b-4bc3-4df7-8a09-765794883524
This field was supposed to store the number of root buses created; however
we don't need to keep that count persistently. After the entry point returns,
nothing reads this field.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17961 6f19259b-4bc3-4df7-8a09-765794883524
On output, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration() function
produces a pointer to a buffer of ACPI 2.0 resource descriptors:
Resources A pointer to the ACPI 2.0 resource descriptors that describe
the current configuration of this PCI root bridge. The
storage for the ACPI 2.0 resource descriptors is allocated by
this function. The caller must treat the return buffer as
read-only data, and the buffer must not be freed by the
caller.
PciHostBridgeDxe currently provides this buffer in a structure with static
storage duration. If multiple root bridges existed in parallel, the
pointers returned by their Configuration() methods would point to the same
static storage. A later Configuration() call would overwrite the storage
pointed out by an earlier Configuration() call (which was possibly made
for a different, but still alive, root bridge.)
Fix this problem by embedding the configuration buffer in
PCI_ROOT_BRIDGE_INSTANCE.
While we're at it, correct some typos (Desp -> Desc), spell out a missing
pack(1) pragma, and improve formatting.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17960 6f19259b-4bc3-4df7-8a09-765794883524
The entry point of the driver, InitializePciHostBridge(), leaks resources
(and installed protocols) in the following cases:
- The first root bridge protocol installation fails. In this case, the
host bridge protocol is left installed, but the driver exits with an
error.
- The second or a later root bridge protocol installation fails. In this
case, the host bridge protocol, and all prior root bridge protocols, are
left installed, even though the driver exits with an error.
Handle errors correctly: roll back / release / uninstall resources when
aborting the driver.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17959 6f19259b-4bc3-4df7-8a09-765794883524
This new function incorporates the current loop body found in the entry
point function, InitializePciHostBridge(). It will be called once for each
root bus discovered.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17958 6f19259b-4bc3-4df7-8a09-765794883524
Currently we define a device path for each root bridge statically (for all
one of them). Since we'll want to create a dynamic number of root bridges,
replace the static device paths with a common template, embed the actual
device path into the private root bridge structure, and distinguish the
device paths from each other in the UID field (as required by ACPI).
This patch is best viewed with "git show -b".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17957 6f19259b-4bc3-4df7-8a09-765794883524
There is no need to store these constants in dedicated static storage
duration objects; we can simply open-code them, simplifying the code.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17956 6f19259b-4bc3-4df7-8a09-765794883524
The entry point function of this driver, InitializePciHostBridge(), and
the static storage duration objects it relies on, are speculatively
generic -- they nominally support more than one host bridges, but (a) the
code hardwires the number of host bridges as 1, (b) it's very unlikely
that we'd ever like to raise that number (especially by open-coding it).
So let's just remove the the nominal support, and simplify the code.
This patch is best viewed with "git show -b".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17955 6f19259b-4bc3-4df7-8a09-765794883524
Currently we only connect the root bus with bus number 0, by device path.
Soon we will possibly have several extra root buses, so connect all root
buses up-front (bus number zero and otherwise), by protocol GUID.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17954 6f19259b-4bc3-4df7-8a09-765794883524
The ASSERT() in SetPciIntLine() assumes that Device 0 on "the" root bus
corresponds to the PCI host bridge (00:00). This used to be true, but
because we're going to have extra root buses (with nonzero bus numbers),
soon this assumption may no longer hold. Check for the zero root bus
number explicitly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17953 6f19259b-4bc3-4df7-8a09-765794883524
These messages are helpful for comparing the assignments made by OVMF
against those made by SeaBIOS. To SeaBIOS a small debug patch like the
following can be applied:
> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> index ac39d23..9e61c22 100644
> --- a/src/fw/pciinit.c
> +++ b/src/fw/pciinit.c
> @@ -308,8 +308,12 @@ static void pci_bios_init_device(struct pci_device *pci)
>
> /* map the interrupt */
> int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
> - if (pin != 0)
> - pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin));
> + if (pin != 0) {
> + int irqline = pci_slot_get_irq(pci, pin);
> +
> + pci_config_writeb(bdf, PCI_INTERRUPT_LINE, irqline);
> + dprintf(1, "assigned irq line %d\n", irqline);
> + }
>
> pci_init_device(pci_device_tbl, pci, NULL);
>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17952 6f19259b-4bc3-4df7-8a09-765794883524
The source code is copied verbatim, with the following two exceptions:
- the UNI files are dropped, together with the corresponding UNI
references in the INF file,
- the INF file receives a new FILE_GUID.
The OVMF DSC and FDF files are at once flipped to the cloned driver.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17951 6f19259b-4bc3-4df7-8a09-765794883524
The FileReserved variable in QemuFwCfgFindFile() is only used to skip
over the reserved field in file headers, which causes newer versions of
GCC to flag it with a "variable set but not used" warning (which is normally
not visible since as of right now these warnings are supressed). It's true
that the value read into FileReserved is never used, but this is
intentional. This patch adds a do-nothing reference to silence the
warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bill Paul <wpaul@windriver.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17920 6f19259b-4bc3-4df7-8a09-765794883524
Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol,
which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).
Therefore we can remove Ip4ConfigDxe driver from this build.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17914 6f19259b-4bc3-4df7-8a09-765794883524
PeiCore hang when loads a PEIM whose section alignment requirement is 0x40
but the actual base address is 0x20 aligned.
The issue is caused by the following facts, in order:
1. GCC49 requires the section alignment of .data to be 0x40. So a new link
script gcc4.9-ld-script was added for GCC49 to specify the 0x40
alignment.
2. GenFw tool was enhanced to sync ELF's section alignment to PE header.
Before the enhancement, the section alignment of converted PE image
always equals to 0x20.
If only with #1 change, GCC49 build image won't hang in PeiCore because
the converted PE image still claims 0x20 section alignment which is
aligned to the align setting set in FDF file. But later with #2 change,
the converted PE image starts to claims 0x40 section alignment, while
build tool still puts the PEIM in 0x20 aligned address, resulting the
PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT
error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524
The bash binary can be in various locations depending on the system: on Linux
it's in /bin while on BSD it's normally in /usr/local/bin. However, the
env binary is almost always in /usr/bin and so can be used to find and start
the shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran <bruce@cran.org.uk>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17883 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17806 6f19259b-4bc3-4df7-8a09-765794883524
AuthVariableLib and TpmMeasurementLib library classes are now linked with
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
to optionally support secure variables.
For OvmfPkg,
link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg
when SECURE_BOOT_ENABLE = TRUE,
and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg
when SECURE_BOOT_ENABLE = FALSE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-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@17760 6f19259b-4bc3-4df7-8a09-765794883524
At the moment we work with a UC default MTRR type, and set three memory
ranges to WB:
- [0, 640 KB),
- [1 MB, LowerMemorySize),
- [4 GB, 4 GB + UpperMemorySize).
Unfortunately, coverage for the third range can fail with a high
likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
the size (UpperMemorySize) differ, then MtrrLib creates a series of
variable MTRR entries, with power-of-two sized MTRR masks. And, it's
really easy to run out of variable MTRR entries, dependent on the
alignment difference.
This is a problem because a Linux guest will loudly reject any high memory
that is not covered my MTRR.
So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
- flip the MTRR default type to WB,
- set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
type and variable MTRRs, so we can't avoid this,
- set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
- set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
more likely than the other scheme (due to less chaotic alignment
differences).
Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000)
in PcdDebugPrintErrorLevel.
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17722 6f19259b-4bc3-4df7-8a09-765794883524
Maoming reported that guest memory sizes equal to or larger than 64GB
were not correctly handled by OVMF.
Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and
starting QEMU with 64GB guest RAM size, I found the following error in the
OVMF debug log:
> GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000)
> GcdMemoryType = Reserved
> Capabilities = 030000000000000F
> Status = Unsupported
This message is emitted when the DXE core is initializing the memory space
map, processing the "above 4GB" memory resource descriptor HOB that was
created by OVMF's QemuInitializeRam() function (see "UpperMemorySize").
The DXE core's call chain fails in:
CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
CoreConvertSpace()
//
// Search for the list of descriptors that cover the range BaseAddress
// to BaseAddress+Length
//
CoreSearchGcdMapEntry()
CoreSearchGcdMapEntry() fails because the one entry (with type
"nonexistent") in the initial GCD memory space map is too small, and
cannot be split to cover the memory space range being added:
> GCD:Initial GCD Memory Space Map
> GCDMemType Range Capabilities Attributes
> ========== ================================= ================ ================
> NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000
The size of this initial entry is determined from the CPU HOB
(CoreInitializeGcdServices()).
Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth,
which is the narrowest valid value to cover the entire guest RAM.
Reported-by: Maoming <maoming.maoming@huawei.com>
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
We'll soon increase the maximum guest-physical RAM size supported by OVMF.
For more RAM, the DXE IPL is going to build more page tables, and for that
it's going to need a bigger chunk from the permanent PEI RAM.
Otherwise CreateIdentityMappingPageTables() would fail with:
> DXE IPL Entry
> Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi
> Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260
> AllocatePages failed: No 0x40201 Pages is available.
> There is only left 0x3F1F pages memory resource to be allocated.
> ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123):
> BigPageAddress != 0
(The above example belongs to the artificially high, maximal address width
of 52, clamped by the DXE core to 48. The address width of 48 bits
corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging
structures.)
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Brian J. Johnson <bjohnson@sgi.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brian J. Johnson <bjohnson@sgi.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Gary Ching-Pang Lin
Star Zeng
Ard Biesheuvel
Bill Paul
Jiaxin Wu
Ruiyu Ni
Bruce Cran
Jordan Justen