Re: [edk2-devel] [PATCH v2 03/11] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg

["Christoph Willing" <chris.willing@linux.com>]

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?

Thanks,
chris