Implement LsiScsiGetDriverName() and LsiScsiGetDeviceName()
to report the name of the driver.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-4-glin@suse.com>
Create the driver with only a dummy LsiScsiEntryPoint() for the further
implementation of the driver for LSI 53C895A SCSI controller.
v2: Fix the mixed-case GUID string
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200717061130.8881-2-glin@suse.com>
The token value of PcdMptScsiStallPerPollUsec should be 0x3a since the
previous token value is 0x39.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Nikita Leshenko <nikita.leshchenko@oracle.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20200715082031.30978-1-glin@suse.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
[lersek@redhat.com: clarify subject, fix typos in commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
RestoreTPL called while at TPL_HIGH_LEVEL unconditionally enables
interrupts even if called in interrupt handler. That opens a window while
interrupt is not completely handled but another interrupt could be
accepted.
If a VM starts on a heavily loaded host hundreds of periodic timer
interrupts might be queued while vCPU is descheduled (the behavior is
typical for a Xen host). The next time vCPU is scheduled again all of them
get delivered back to back causing OVMF to accept each one without
finishing a previous one and cleaning up the stack. That quickly results
in stack overflow and a triple fault.
Fix it by postponing sending EOI until we finished processing the current
tick giving interrupt handler opportunity to clean up the stack before
accepting the next tick.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786
Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
This reverts commit ced77332ca.
The command
virt-install --location NETWORK-URL
downloads the vmlinuz and initrd files from the remote OS tree, and passes
them to the guest firmware via fw_cfg.
When used with IA32 / X64 guests, virt-install expects the guest firmware
to do two things, at the same time:
- launch the fw_cfg kernel image even if the latter does not pass SB
verification (SB checking is supposed to be bypassed entirely in favor
of the Linux/x86 Boot Protocol),
- still let the guest kernel perceive SB as enabled.
Commit ced77332ca prevented this, by removing the Linux/x86 Boot
Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE.
While that's the right thing in theory, in practice "virt-install
--location NETWORK-URL" is entrenched, and we shouldn't break it.
We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass
for direct-booted kernels, because:
- the fw_cfg content comes from QEMU, and the guest is already at QEMU's
mercy,
- in the guest, OS boots after the initial installation will use "shim"
rather than an fw_cfg kernel, which we can consider somewhat similar to
"Audit Mode / Deployed Mode" (~ trust for install, lock down after).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20200615144514.24597-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[lersek@redhat.com: truncate the subject line, originally auto-generated
by git-revert, to pacify PatchCheck.py]
gBS->LoadImage() returning EFI_NOT_FOUND is an expected condition; it
means that QEMU wasn't started with "-kernel". Log this status code as
INFO rather than ERROR.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200609105414.12474-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
When an image fails Secure Boot validation, LoadImage() returns
EFI_SECURITY_VIOLATION if the platform policy is
DEFER_EXECUTE_ON_SECURITY_VIOLATION.
If the platform policy is DENY_EXECUTE_ON_SECURITY_VIOLATION, then
LoadImage() returns EFI_ACCESS_DENIED (and the image does not remain
loaded).
(Before <https://bugzilla.tianocore.org/show_bug.cgi?id=2129>, this
difference would be masked, as DxeImageVerificationLib would incorrectly
return EFI_SECURITY_VIOLATION for DENY_EXECUTE_ON_SECURITY_VIOLATION as
well.)
In X86QemuLoadImageLib, proceed to the legacy Linux/x86 Boot Protocol upon
seeing EFI_ACCESS_DENIED too.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2785
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200605235242.32442-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
BaseLib interfaces (namely, SwapBytesXx()) are only used in
"Tpm12Support.c", which is IA32/X64-only. Therefore the BaseLib class
dependency should also be restricted to IA32 & X64, in the INF file.
The "#include <Library/BaseLib.h>" directive is already present in
"Tpm12Support.c" only.
(The BaseLib dependency should have been restricted to IA32 and X64
together with the Tpm12DeviceLib dependency, as part of commit
74f90d38c4, "OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building
for ARM/AARCH64", 2020-05-21.)
This is a trivial cleanup; functionally a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The leading comments in "Tcg2ConfigPei.inf" and "Tcg2ConfigPeim.c" say,
"In OvmfPkg, the module only performs TPM2 hardware detection".
The statement hasn't been correct since commit 8923699291 ("OvmfPkg:
detect TPM 1.2 in Tcg2ConfigPei", 2020-03-04). Replace "TPM2" with "TPM"
(without stating a version) in those file-top comments.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Dating back to commits f5cb376703 and ddd34a8183, the
"ArmVirtPkg/ArmVirtQemu.dsc" platform includes the
"OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE
build flag is defined.
This was regressed in commit 8923699291, which added a Tpm12DeviceLib
dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class
to any instance, so now we get a build failure:
> build.py...
> ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class
> [Tpm12DeviceLib] is not found
> in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64]
> consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf]
The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case
(a kind of physical TPM-1.2 assignment), and that has never applied to
"ArmVirtQemu.dsc".
Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of
OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency.
Functionally, this patch is a no-op on IA32 / X64.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Move the calls to the Tpm12RequestUseTpm() and Tpm12SubmitCommand()
Tpm12DeviceLib functions to a separate C file, so that we can override
these actions in a subsequent patch.
This code movement requires moving the TPM_RSP_GET_TICKS / TestTpm12()
helper structure / function too.
While at it, give the TestTpm12() function @retval / @return
documentation, plus wrap an overlong line in it.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Commit 8923699291 introduced an explicit Tpm12CommandLib dependency to
Tcg2ConfigPei.
In reality this lib class is not consumed by Tcg2ConfigPei at all (such a
dependency is not even inherited from other lib instances). Simplify the
module by dropping the superfluous dependency.
(The Tpm12CommandLib class resolution that was also added in commit
8923699291 is not useless, at the platform build level: it is consumed
by TcgPei and TcgDxe. Meaning that said Tpm12CommandLib resolution should
have likely been a part of the subsequent patch in the original series,
namely commit 6be54f15a0c9.)
Commit 8923699291 also introduced SwapBytesXx() calls. Those functions
are provided by BaseLib. Spell out the BaseLib dependency.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Any new OVMF binary (containing commit d42fdd6f83, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace
the open-coded memory type info defaults in the source code with the
EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform
builders can override these values with the "--pcd" option of "build",
without source code updates.
While at it, sort the memory type names alphabetically.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
In commit d42fdd6f83 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.
Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:
[1] https://edk2.groups.io/g/devel/message/55741http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97B579@shsmsx102.ccr.corp.intel.com
[2] https://edk2.groups.io/g/devel/message/55749http://mid.mail-archive.com/74D8A39837DF1E4DA445A8C0B3885C503F97BDC5@shsmsx102.ccr.corp.intel.com
While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:
- such reboots during normal boot that look "spurious" to the end user,
and have no SMM security benefit,
- a large BS Data record in MemoryTypeInformation may cause issues when
the DXE Core tries to prime the according bin(s), but the system's RAM
size has been reduced meanwhile.
Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
OVMF booting stops with the assert if built with Xcode on macOS:
Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398
ProtectUefiImageCommon - 0x1F218140
- 0x000000001FAB8000 - 0x0000000000008A60
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status)
The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.
Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d9
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain
Fixes: ec41733cfd ("OvmfPkg: add the 'initrd' dynamic shell command")
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340
During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in
place of the standard library when building with the XCODE5 toolchain.
The SEC XCODE5 version of the library performs binary patching and should
only be used when building with the XCODE5 toolchain.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This causes the device to forget about the reply frame. We allocated the
reply frame in EfiBootServicesData type memory, and code executing after
ExitBootServices() is permitted to overwrite it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-13-nikita.leshchenko@oracle.com>
Machines should be able to boot after this commit. Tested with different
Linux distributions (Ubuntu, CentOS) and different Windows
versions (Windows 7, Windows 10, Server 2016).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com>
[lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.
See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for more information.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Message-Id: <20200504210607.144434-11-nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enable the IO Space and Bus Mastering and restore the original values
when the device is stopped. This is a standard procedure in PCI
drivers.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-10-nikita.leshchenko@oracle.com>
This will give us an exclusive access to the PciIo of this device
after it was started and until is will be stopped.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-9-nikita.leshchenko@oracle.com>
The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
Support dynamic insertion and removal of the protocol
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-6-nikita.leshchenko@oracle.com>
The MptScsiControllerSupported function is called on handles passed in
by the ConnectController() boot service and if the handle is the
lsi53c1030 controller the function would return success. A successful
return value will attach our driver to the device.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-5-nikita.leshchenko@oracle.com>
Install Component Name protocols to have a nice display name for the
driver in places such as UEFI shell.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-4-nikita.leshchenko@oracle.com>
In order to probe and connect to the MptScsi device we need this
protocol. Currently it does nothing.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200504210607.144434-3-nikita.leshchenko@oracle.com>
Add a null implementation library for QemuFwCfgLib, in order to
support building PciHostBridgeLib for bhyve.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200503230910.26783-1-rebecca@bsdio.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
On bhyve, the ACPI timer is located at a fixed IO address; it need
not be programmed into, nor fetched from, the PMBA -- power
management base address -- register of the PCI host bridge.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20200430011212.612386-1-rebecca@bsdio.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
QEMU switches:
-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn]
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn]
The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation
from QEMU's "docs/specs/fw_cfg.txt".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We don't distribute UEFI_DRIVER modules stand-alone that were built as
part of an OVMF platform. OVMF's UEFI_DRIVERs are allowed to inherit
platform dependencies.
By enabling UEFI_DRIVERs to consume QemuFwCfgDxeLib, we can hook
fw_cfg-based NULL class libraries into UEFI drivers, e.g. in order to set
dynamic PCDs.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The UPDATE_BOOLEAN_PCD_FROM_FW_CFG() macro currently calls the
module-private helper function GetNamedFwCfgBoolean(). Replace the latter
with QemuFwCfgParseBool() from QemuFwCfgSimpleParserLib.
This change is compatible with valid strings accepted previously.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Replace the
- QemuFwCfgFindFile(),
- QemuFwCfgSelectItem(),
- QemuFwCfgReadBytes(),
- AsciiStrDecimalToUint64()
sequence in the GetFirstNonAddress() function with a call to
QemuFwCfgSimpleParserLib.
This change is compatible with valid strings accepted previously.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
We already parse some boolean and integer values from named fw_cfg files
(usually into PCDs), and we're going to cover more. Add a dedicated
library for centralizing the parsing logic.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-2-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging
debug output to the Xen console.
This will work with both Xen HVM guest and Xen PVH guest whereas the
default PlatformDebugLibIoPort works only in HVM when QEMU is present.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Introduce PlatformRomDebugLibIoPortNocheck which doesn't try to detect
the debug IO port. Instead, debug logs are always written to the IO port.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-5-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Factor out debug port detection in PlatformDebugLibIoPort.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-4-anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
We are going to reuse PlatformDebugLibIoPort to use debug IO port from
hypervisors that aren't QEMU, so reword "QEMU" to "hypervisor" in the
descriptions.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-3-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build
with it due to a circular dependency:
DebugLib : BaseDebugLibSerialPort ->
SerialPortLib : XenConsoleSerialPortLib ->
XenHypercallLib : XenHypercallLib ->
DebugLib
Also, if that dependency is fixed, I think it would be harder to find
which console the debug is sent to when running an HVM guest. The xen
console isn't the serial console used by default. Furthermore,
XenHypercallLib isn't initialised early enough, so we would loose
debug output from the SEC phase and early PEI phase.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2570
Add new Azure Pipeline definitions to build and run OvmfPkg with:
* Ubuntu GCC5
* Windows VS2019
Add PyTool based build of OvmfPkg
Add extdep for managing the iasl dependency
Add OvmfPkg.ci.yaml for Core CI
Add ReadMe.md for details and instructions
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
In preparation for introducing DxeResetSystemLib, rename the current
(only) ResetSystemLib instance to BaseResetSystemLib.
In the DSC files, keep the ResetSystemLib resolution in the same
[LibraryClasses] section, but move it near the TimerLib resolution, as the
differences between the ResetSystemLib instances will mostly follow those
seen under OvmfPkg/Library/AcpiTimerLib.
(While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the
same movement there too, for keeping future DSC diffing simple.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-6-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Move the ResetShutdown() definition to its own file. This will help us
introduce:
- a new library instance that is not broken in runtime modules (the
current library instance is broken in runtime modules),
- another new library instance for bhyve support.
While at it, squash AcpiPmControl() into ResetShutdown(), open-coding
SuspendType=0. This is justified because we've had no other callers for
AcpiPmControl() since commit 2d9950a2bf ("OvmfPkg: remove
EnterS3WithImmediateWake () from ResetSystemLib", 2020-01-10).
Tested with the "reset -s" UEFI shell command, on both i440fx and q35.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-5-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The cases under ResetSystem() currently mix "break"s with "return"s for no
good reason. Use "break" consistently.
(The inconsistency was introduced in commit 84c0b80de7,
"OvmfPkg/ResetSystemLib: Add new API ResetSystem", 2019-04-28.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-4-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Annotate the #include directives with the interfaces that this lib
instance needs from the included lib class headers. This will help us keep
the #include set minimal, when we move code around later.
While at it, synchronize the [LibraryClasses] section with the #include
directives -- list BaseLib.
Also #include the ResetSystemLib class header, which declares the
interfaces that this lib instance implements.
This forces us to spell out the "MdeModulePkg.dec" dependency too, under
[Packages].
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
The UEFI properties table and the associated memory protection feature was
severely broken from the start, and has been deprecated for a while. Let's
drop all references to it from OVMF so we can safely remove it from the
DXE core as well.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Previous to this change, PvScsiFreeRings() was not undoing all
operations that was done by PvScsiInitRings().
This is because PvScsiInitRings() was both preparing rings (Allocate
memory and map it for device DMA) and setup the rings against device by
issueing a device command. While PvScsiFreeRings() only unmaps the rings
and free their memory.
Driver do not have a functional error as it makes sure to reset device
before every call site to PvScsiFreeRings(). However, this is not
intuitive.
Therefore, prefer to refactor the setup of the ring against device to a
separate function than PvScsiInitRings().
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200331225637.123318-1-liran.alon@oracle.com>
[lersek@redhat.com: rename FreeDMACommBuffer label to FreeDmaCommBuffer]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Sean reported that VS2019 build produce the following build error:
INFO - PvScsi.c
INFO - Generating code
INFO - d:\a\1\s\OvmfPkg\PvScsiDxe\PvScsi.c(459): error C2220: the
following warning is treated as an error
INFO - d:\a\1\s\OvmfPkg\PvScsiDxe\PvScsi.c(459): warning C4244: '=':
conversion from 'const UINT16' to 'UINT8', possible loss of data
This result from an implicit cast from PVSCSI Response->ScsiStatus
(Which is UINT16) to Packet->TargetResponse (Which is UINT8).
Fix this issue by adding an appropriate explicit cast and verify with
assert that this truncation do not result in loss of data.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2651
Reported-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200331110452.51992-1-liran.alon@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: rewrap VS2019 diags in commit msg for PatchCheck.py]
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2642
This patch resolves the problem of using memory protection
attributes when OVMF firmware is compiled with XCODE5 and CLANGPDB.
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
Message-Id: <20200329132158.35259-2-cheptsov@ispras.ru>
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix whitespace issues reported by git-am]
[lersek@redhat.com: replace "CC:" tags with "Cc:" ones for PatchCheck.py]
This causes the device to forget about the request/completion rings.
We allocated said rings in EfiBootServicesData type memory, and code
executing after ExitBootServices() is permitted to overwrite it.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-17-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Implement EXT_SCSI_PASS_THRU.PassThru().
Machines should be able to boot after this commit.
Tested with Ubuntu 16.04 guest.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-16-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In case device is constrained by IOMMU or guest is running under AMD SEV,
input/output buffers provided to device (DataBuffer and SenseData) needs
to be explicitly mapped to device by PciIo->Map().
To avoid the overhead of mapping/unmapping the DataBuffer and SenseData
to the device for every SCSI requst (and to simplify code), introduce a
single DMA communication buffer that will be mapped to device on
initialization. When a SCSI request needs to be sent to device, the
DataBuffer and SenseData will be copied from/to the DMA communication
buffer as required. This will be done by the following commits.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-15-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
These rings are shared memory buffers between host and device in which
a cyclic buffer is managed to send request descriptors from host to
device and receive completion descriptors from device to host.
Note that because device may be constrained by IOMMU or guest may be run
under AMD SEV, we make sure to map these rings to device by using
PciIo->Map().
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-14-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
These definitions will be used by the following commits to complete the
implementation of PVSCSI device driver.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-12-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
This commit doesn't change semantics.
It is done as a preparation for future commits which will modify
PCI attributes.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-10-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
This will give us an exclusive access to the PciIo of this device
after it was started and until it will be stopped.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-9-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Implement EXT_SCSI_PASS_THRU.GetNextTarget() and
EXT_SCSI_PASS_THRU.GetNextTargetLun().
ScsiBusDxe scans all MaxTarget * MaxLun possible devices.
This can take unnecessarily long for large number of targets.
To deal with this, VirtioScsiDxe has defined PCDs to limit the
MaxTarget & MaxLun to desired values which gives sufficient
performance. It is very important in virtio-scsi as it can have
very big MaxTarget & MaxLun.
Even though a common PVSCSI device has a default MaxTarget=64 and
MaxLun=0, we implement similar mechanism as virtio-scsi for completeness.
This may be useful in the future when PVSCSI will have bigger values
for MaxTarget and MaxLun.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-7-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
PvScsiControllerSupported() is called on handles passed in
by the ConnectController() boot service and if the handle is the
PVSCSI controller, the function would return success. A success
return value will attach our driver to the device.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-5-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Install Component Name protocols to have a nice display name for the
driver in places such as UEFI shell.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-4-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
In order to probe and connect to the PvScsi device we need this
protocol. Currently it does nothing.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-3-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
In preparation for support booting from PvScsi devices, create a
basic scaffolding for a driver.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200328200100.60786-2-liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Building OVMF for X64 with secure boot enabled on VS2019 results in
the following error:
d:\a\1\s\OvmfPkg\Library\GenericQemuLoadImageLib\GenericQemuLoadImageLib.c(154):
error C2220: the following warning is treated as an error
d:\a\1\s\OvmfPkg\Library\GenericQemuLoadImageLib\GenericQemuLoadImageLib.c(154):
warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
Suppress the error by making the cast explicit.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2636
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
GCC 4.8 or 4.9 may throw the following error when building OVMF:
Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:
In function ‘QemuLoadKernelImage’:
Edk2/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c:416:30:
error: ‘CommandLine’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
UnicodeSPrintAsciiFormat (
cc1: all warnings being treated as errors
This is due to the fact that older GCCs fail to infer that CommandLine is
never actually used unless it has been assigned. So add a redundant NULL
assignment to help these older GCCs understand this.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2630
Fixes: 7c47d89003 ("OvmfPkg: implement QEMU loader library for X86 with ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2582
warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Leif suggested that FDF include files should preferably refer with their
names to the FDF file sections from which they are included.
Therefore
- rename "OvmfPkg.fdf.inc" to "OvmfPkgDefines.fdf.inc" (included from the
[Defines] section),
- rename "DecomprScratchEnd.fdf.inc" to "FvmainCompactScratchEnd.fdf.inc"
(included under the [FV.FVMAIN_COMPACT] section).
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: http://mid.mail-archive.com/20200312142006.GG23627@bivouac.eciton.net
Ref: https://edk2.groups.io/g/devel/message/55812
Suggested-by: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200312223555.29267-3-lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Add a code comment that explains the nature of the NumberOfPages field
values. Including this kind of historical information was suggested by
Leif in <https://edk2.groups.io/g/devel/message/55797> (alternative link:
<http://mid.mail-archive.com/20200312104006.GB23627@bivouac.eciton.net>).
Right now, the most recent commit updating the page counts has been commit
991d956362 ("[...] Update default memory type information to reduce EFI
Memory Map fragmentation.", 2010-07-16).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200312223555.29267-2-lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Secure SMM Communication
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papershttps://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
--^--
bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call
for action", recommend enabling the (adaptive) Memory Type Information
feature.
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papershttps://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
--^--
figure#6 describes the Memory Type Information feature in detail; namely
as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE
Core, and BDS.
Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling
the Secure SMM Communication recommendation.
In the longer term, OVMF should install the WSMT ACPI table, and this
patch contributes to that.
Notes:
- the step in figure#6 where the UEFI variable is copied into the HOB is
covered by the DXE IPL PEIM, in the DxeLoadCore() function,
- "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC
default TRUE value, because both whitepapers indicate that BDS needs to
reset the system if the Memory Type Information changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-6-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
FaultTolerantWritePei consumes:
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase.
VariablePei consumes:
- PcdFlashNvStorageVariableBase64.
Due to the previous patches in this series, the above PCDs are available
in the PEI phase, in the SMM_REQUIRE build.
FaultTolerantWritePei produces a GUID-ed HOB with
FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null
PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB.
VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes
the HOB (which is safe due to the DEPEX), and produces
EFI_PEI_READ_ONLY_VARIABLE2_PPI.
This enables read-only access to non-volatile UEFI variables in the PEI
phase, in the SMM_REQUIRE build.
For now, the DxeLoadCore() function in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the
"MemoryTypeInformation" variable, because OVMF's PlatformPei always
produces the MemoryTypeInformation HOB.
(Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build
the HOB, but that's in sync with DxeLoadCore() also not looking for either
the HOB or the UEFI variable.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-5-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
The following flash-related base addresses:
- PcdFlashNvStorageVariableBase64,
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase,
are always set to constant (invariable) values in the "-D SMM_REQUIRE"
build of OVMF. (That's because in the SMM build, actual pflash is a hard
requirement, and the RAM-based emulation is never available.)
Set said PCDs statically, at build. This will allow us to depend on their
values in the PEI phase.
When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report
file comparison).
When SMM_REQUIRE is TRUE, the report file shows the following changes:
- "PcdOvmfFlashNvStorageFtwSpareBase" and
"PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any
module directly,
- for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase"
and "PcdFlashNvStorageVariableBase64", the access method changes from
DYN to FIXED,
- for the latter PCDs, the zero (dynamic default) values are replaced with
the desired constants.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-4-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Extract the dynamic setting of the
- PcdFlashNvStorageVariableBase64
- PcdFlashNvStorageFtwWorkingBase
- PcdFlashNvStorageFtwSpareBase
addresses to a helper function.
For now, the helper function is identical (duplicated) between the SMM
flash driver and the runtime DXE flash driver. In subsequent patches, this
will change.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-3-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
The only two OvmfPkg references to "PcdFlashNvStorageVariableBase" are the
spurious ones in the runtime DXE driver and the SMM driver INF files of
the QEMU flash driver. Remove these references.
The flash driver does not access "PcdOvmfFlashNvStorageEventLogBase"
either, so remove that from the INF files too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-2-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2580
Ovmf build failed on Windows with VS2017 tool chain.
The error message like:
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitr
dDynamicShellCommand.c(199): error C2220: warning treated as error -
no 'object' file generated
OvmfPkg\LinuxInitrdDynamicShellCommand\LinuxInitrdDynamicShellCommand.c(199):
warning C4244: '=': conversion from 'UINT64' to 'UINTN',
possible loss of data
This patch is to cast UINT64 type to UINTN type
when doing the variable assignment.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Similarly to the "cadence" mentioned in commit d272449d9e ("OvmfPkg:
raise DXEFV size to 11 MB", 2018-05-29), it's been ~1.75 years, and we've
outgrown DXEFV again. Increase the DXEFV size to 12MB now.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2585
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310175025.18849-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.
Move the local variable to the inner scope, where declaration and usage
are inseparable.
(Note that such inner-scope declarations are frowned upon in the wider
edk2 codebase, but we use them liberally in ArmVirtPkg and OvmfPkg anyway,
because they help us reason about variable lifetime and visibility.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 7c47d89003
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2572
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Bob reports that VS2017 chokes on a tentative definition of the const
object 'mEfiFileProtocolTemplate', with the following error:
OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130):
error C2220: warning treated as error - no 'object' file generated
OvmfPkg\QemuKernelLoaderFsDxe\QemuKernelLoaderFsDxe.c(130):
warning C4132: 'mEfiFileProtocolTemplate': const object should be initialized
Let's turn the only function that relies on this tentative definition
into a forward declaration itself, and move its definition after the
external definition of the object. That allows us to drop the tentative
definition of the const object, and hopefully make VS2017 happy.
Cc: "Feng, Bob C" <bob.c.feng@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Commit 859b55443a ("OvmfPkg/PlatformBootManagerLib: switch to
QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on
QemuLoadImageLib in the PlatformBootManagerLib implementation that is
shared between all OVMF builds, without taking into account that even
the Xen targeted builds incorporate this code, which is only used to
load kernels passed via the QEMU command line.
Since this is dead code on Xen, we can satisfy the dependency using
the generic version of QemuLoadImageLib, which does not rely on
LoadLinuxLib, which we can therefore drop from OvmfXen.dsc.
Fixes: 859b55443a
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The QemuLoadImageLib implementation we currently use for all OVMF
builds copies the behavior of the QEMU loader code that precedes it,
which is to disregard UEFI secure boot policies entirely when it comes
to loading kernel images that have been specified on the QEMU command
line. This behavior deviates from ArmVirtQemu based builds, which do
take UEFI secure boot policies into account, and refuse to load images
from the command line that cannot be authenticated.
The disparity was originally due to the fact that the QEMU command line
kernel loader did not use LoadImage and StartImage at all, but this
changed recently, and now, there are only a couple of reasons left to
stick with the legacy loader:
- it permits loading images that lack a valid PE/COFF header,
- it permits loading X64 kernels on IA32 firmware running on a X64
capable system.
Since every non-authentic PE/COFF image can trivially be converted into
an image that lacks a valid PE/COFF header, the former case can simply
not be supported in a UEFI secure boot context. The latter case is highly
theoretical, given that one could easily switch to native X64 firmware in
a VM scenario.
That leaves us with little justification to use the legacy loader at all
when UEFI secure boot policies are in effect, so let's switch to the
generic loader for UEFI secure boot enabled builds.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Linux v5.7 will introduce a new method to load the initial ramdisk
(initrd) from the loader, using the LoadFile2 protocol installed on a
special vendor GUIDed media device path.
Add support for this to our QEMU command line kernel/initrd loader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Replace the open coded sequence to load Linux on x86 with a short and
generic sequence invoking QemuLoadImageLib, which can be provided by
a generic version that only supports the LoadImage and StartImage boot
services, and one that incorporates the entire legacy loading sequence
as well.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add the components that expose the QEMU abstract loader file system so
that we can switch over our PlatformBmLib over to it in a subsequent
patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Implement another version of QemuLoadImageLib that uses LoadImage and
StartImage, but falls back to the legacy Linux loader code if that
fails. The logic in the legacy fallback routines is identical to the
current QEMU linux loader for X64 and IA32.
Note the use of the OVMF_LOADED_X86_LINUX_KERNEL protocol for the legacy
loaded image: this makes it possible to expose the LoadImage/StartImage
abstraction for the legacy loader, using the EFI paradigm of identifying
a loaded image solely by a handle.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In preparation of moving the legacy x86 loading to an implementation
of the QEMU load image library class, introduce a protocol header
and GUID that we will use to identify legacy loaded x86 Linux kernels
in the protocol database.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
On x86, the kernel image consists of a setup block and the actual kernel,
and QEMU presents these as separate blobs, whereas on disk (and in terms
of PE/COFF image signing), they consist of a single image.
So add support to our FS loader driver to expose files via the abstract
file system that consist of up to two concatenated blobs, and redefine
the kernel file so it consists of the setup and kernel blobs, on every
architecture (on non-x86, the setup block is simply 0 bytes and is
therefore ignored implicitly)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
We have no need for exposing the kernel command line as a file,
so remove support for that. Since the remaining blobs (kernel
and initrd) are typically much larger than a page, switch to
the page based allocator for blobs at the same time.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Implement QemuLoadImageLib, and make it load the image provided by the
QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented
in a preceding patch in a separate DXE driver, using only the standard
LoadImage and StartImage boot services.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Gary Lin
Igor Druzhinin
Tan, Ming
Laszlo Ersek
Roman Bolshakov
Lendacky, Thomas
Nikita Leshenko
Rebecca Cran
Anthony PERARD
Sean Brogan
Ard Biesheuvel
Liran Alon
Vitaly Cheptsov
Ard Biesheuvel
Liming Gao
Bob Feng