When the user doesn't pass a kernel with QEMU's "-kernel" switch, the
firmware sees a zero-sized kernel blob via the QemuFwCfgItemKernelSize
key; there's no way to distinguish "no kernel" from "zero sized kernel".
In both cases TryRunningQemuKernel() proceeds as far as gBS->LoadImage(),
which then rejects the zero sized synthetic file with EFI_UNSUPPORTED.
This is known and works fully as expected; however we should rather catch
the much more frequent "no kernel" case earlier, in order to avoid the
EFI_D_ERROR message
TryRunningQemuKernel: LoadImage(): Unsupported
which is arguably meaningless noise for the "no kernel" case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16985
6f19259b-4bc3-4df7-8a09-
765794883524
InitrdBlob = &mKernelBlob[KernelBlobTypeInitrd];\r
CommandLineBlob = &mKernelBlob[KernelBlobTypeCommandLine];\r
\r
+ if (KernelBlob->Data == NULL) {\r
+ Status = EFI_NOT_FOUND;\r
+ goto FreeBlobs;\r
+ }\r
+\r
//\r
// Create a new handle with a single VenHw() node device path protocol on it,\r
// plus a custom SimpleFileSystem protocol on it.\r