summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuKernelLoaderFsDxe: drop tentative const object definitionArd Biesheuvel2020-03-081-66/+71
| | | | | | | | | | | | | | | | | | | 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>
* OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device pathArd Biesheuvel2020-03-051-0/+79
| | | | | | | | | | | | 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>
* OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup blockArd Biesheuvel2020-03-051-21/+53
| | | | | | | | | | | | | | | | 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>
* OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command lineArd Biesheuvel2020-03-051-4/+3
| | | | | | | | | | | 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>
* OvmfPkg: export abstract QEMU blob filesystem in standalone driverArd Biesheuvel2020-03-051-0/+979
Expose the existing implementation of an abstract filesystem exposing the blobs passed to QEMU via the command line via a standalone DXE driver. Notable difference with the original code is the switch to a new vendor GUIDed media device path, as opposed to a vendor GUID hardware device path, which is not entirely appropriate for pure software constructs. Since we are using the GetTime() runtime service in a DXE_DRIVER type module, we need to DEPEX explicitly on gEfiRealTimeClockArchProtocolGuid. 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>