From: "Dov Murik" <dovmurik@linux.ibm.com>
To: chris.willing@linux.com, devel@edk2.groups.io
Cc: Dov Murik <dovmurik@linux.ibm.com>
Subject: Re: [edk2-devel] [PATCH v2 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg
Date: Tue, 20 Jul 2021 07:55:56 +0300 [thread overview]
Message-ID: <2c705130-6183-5fb8-c1a5-373fd41a1ad7@linux.ibm.com> (raw)
In-Reply-To: <677eb4b4-98cc-dea5-0cd2-882a504f3125@linux.com>
On 20/07/2021 1:36, Christoph Willing wrote:
> On 20/7/21 3:58 am, Dov Murik wrote:
>>
>>
>> On 19/07/2021 15:56, Christoph Willing wrote:
>>> Thanks for the clarification Dov.
>>>
>>> I've been trying with just "normal" VMs, not SEV. I did already find and try the confidential-containers-demo sev-hashes-v2 branch but it didn't help - not surprising if it's not relevant to normal VMs.
>>>
>>> Do you know whether this functionality (-kernel, -initrd, -append options) is actually supposed to work in normal VMs at the moment? The only conditions under which it works here with qemu-6.0.0 is with vUDK2017 & 2018 and an old ovmf binary package from kraxel.og dated 2017. Anything built from the edk2 master branch has failed when using those qemu options, although all the same builds work perfectly using the VMs' internal kernels & initrds. I've also extracted OVMF files from the current kraxel.org package as well as Ubuntu's (hirsute) package and these also fail the same way i.e. kernel boots and initrd works (loads modules) but then the VM filesystem doesn't seem to be found (no /dev/sdX exists to mount the filesystem root).
>>>
>>> I guess this could be a qemu problem but since it works with some (old) udk/edk2 versions, I thought I'd look here first.
>>>
>>
>>
>> Can you please try with edk2 commit d1fc3d7ef3cb - just before we did
>> some changes around this QEMU-interop code in OVMF?
>>
>
> I just tried a build at d1fc3d7ef3cb... with the same result. Works with
> VM's internal kernel & initrd but not with external (using -kernel,
> -initrd & -append options).
>
> As soon as I revert to OVMF files (CODE & VARS) from vUDK2018, all works
> as expected with external kernel & initrd.
>
> Since this problem seems to go back to around 2018, is it better to
> report in bugzilla?
I think so.
Be sure to include full logs as much as possible and details about the
image you're trying to start; it seems to me that if the kernel starts
and initrd is mounted etc then both QEMU and OVMF are doing their part,
and there's something else that fails (but then again, reverting to an
old OVMF does solve it... IDK).
-Dov
>
> Thanks,
> chris
>
next prev parent reply other threads:[~2021-07-20 4:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 8:54 [PATCH v2 00/11] Measured SEV boot with kernel/initrd/cmdline Dov Murik
2021-07-06 8:54 ` [PATCH v2 01/11] OvmfPkg/AmdSev/SecretDxe: fix header comment to generic naming Dov Murik
2021-07-17 15:16 ` Brijesh Singh
2021-07-06 8:54 ` [PATCH v2 02/11] OvmfPkg/AmdSev: use GenericQemuLoadImageLib in AmdSev builds Dov Murik
2021-07-17 15:18 ` Brijesh Singh
2021-07-06 8:54 ` [PATCH v2 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg Dov Murik
2021-07-17 15:35 ` Brijesh Singh
2021-07-19 4:46 ` [edk2-devel] " Christoph Willing
2021-07-19 12:14 ` Dov Murik
2021-07-19 12:56 ` Christoph Willing
2021-07-19 17:58 ` Dov Murik
2021-07-19 22:36 ` Christoph Willing
2021-07-20 4:55 ` Dov Murik [this message]
2021-07-19 15:21 ` Lendacky, Thomas
2021-07-19 19:14 ` Dov Murik
2021-07-20 7:33 ` Dov Murik
2021-07-20 7:41 ` Ard Biesheuvel
2021-07-06 8:54 ` [PATCH v2 04/11] OvmfPkg: add library class BlobVerifierLib with null implementation Dov Murik
2021-07-17 20:16 ` Brijesh Singh
2021-07-19 15:50 ` Lendacky, Thomas
2021-07-19 19:23 ` Dov Murik
2021-07-06 8:54 ` [PATCH v2 05/11] OvmfPkg: add NullBlobVerifierLib to DSC Dov Murik
2021-07-17 20:18 ` Brijesh Singh
2021-07-06 8:54 ` [PATCH v2 06/11] ArmVirtPkg: " Dov Murik
2021-07-18 15:43 ` Brijesh Singh
2021-07-06 8:54 ` [PATCH v2 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg Dov Murik
2021-07-18 15:47 ` Brijesh Singh
2021-07-19 12:22 ` Dov Murik
2021-07-19 15:19 ` Brijesh Singh
2021-07-19 19:54 ` Dov Murik
2021-07-19 15:57 ` Lendacky, Thomas
2021-07-19 19:30 ` Dov Murik
2021-07-06 8:54 ` [PATCH v2 08/11] OvmfPkg/AmdSev/SecretPei: build hob for full page Dov Murik
2021-07-19 16:19 ` Lendacky, Thomas
2021-07-19 19:37 ` Dov Murik
2021-07-06 8:54 ` [PATCH v2 09/11] OvmfPkg/AmdSev: reserve MEMFD space for for firmware config hashes Dov Murik
2021-07-19 16:38 ` Lendacky, Thomas
2021-07-06 8:55 ` [PATCH v2 10/11] OvmfPkg: add SevHashesBlobVerifierLib Dov Murik
2021-07-19 17:28 ` Lendacky, Thomas
2021-07-19 19:47 ` Dov Murik
2021-07-19 20:15 ` Lendacky, Thomas
2021-07-06 8:55 ` [PATCH v2 11/11] OvmfPkg/AmdSev: Enforce hash verification of kernel blobs Dov Murik
2021-07-19 17:31 ` Lendacky, Thomas
2021-07-16 17:11 ` [edk2-devel] [PATCH v2 00/11] Measured SEV boot with kernel/initrd/cmdline Ard Biesheuvel
2021-07-19 15:14 ` Lendacky, Thomas
2021-07-19 19:12 ` Dov Murik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c705130-6183-5fb8-c1a5-373fd41a1ad7@linux.ibm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox