Re: [edk2-devel] [PATCH v2 2/6] OvmfPkg/AmdSev: add Grub Firmware Volume Package

["Laszlo Ersek" <lersek@redhat.com>]

On 11/25/20 18:09, James Bottomley wrote:
> On Wed, 2020-11-25 at 08:02 -0800, James Bottomley wrote:
>> On Wed, 2020-11-25 at 15:01 +0100, Laszlo Ersek wrote:
>>> This upgrade gave me kernel 5.8.18-100.fc31.x86_64 in the guest --
>>> and this one does *not* crash. From your boot log below, I see your
>>> guest kernel is 5.5.0; I suggest upgrading it.
>>
>> Heh, that's easier said than done ... I always make my encrypted
>> images too small to upgrade a kernel easily.  Anyway, after doing the
>> remove and add stuff dance, I finally got it upgraded to the latest
>> debian testing linux-image-5.8.0-3 it's still crashing although with
>> a slightly different traceback.  It looks like there might be
>> something additional in the fedora 5.8 kernel that fixes this.  I'm
>> going to try out upstream kernels next.
> 
> I've got the upstream kernel booting through OVMF with a qemu -kernel
> command line.  I also have a fix: it's not to delete the dummy variable
> which was part of the ancient x86 anti bricking code (which is also why
> arm64 doesn't have the problem).
> 
> If you remove the set variable in arch/x86/platform/efi/quirks.c:
> 
> /*
>  * Deleting the dummy variable which kicks off garbage collection
> */
> void efi_delete_dummy_variable(void)
> {
> 	efi.set_variable_nonblocking((efi_char16_t *)efi_dummy_name,
> 				     &EFI_DUMMY_GUID,
> 				     EFI_VARIABLE_NON_VOLATILE |
> 				     EFI_VARIABLE_BOOTSERVICE_ACCESS |
> 				     EFI_VARIABLE_RUNTIME_ACCESS, 0, NULL);
> }
> 
> The kernel will boot.  I'm not sure why we have this deletion
> unconditionally in efi_enter_virtual_mode, but removing the call with
> the patch below allows the kernel to boot.

I think commit 2ecb7402cfc7 ("efi/x86: Do not clean dummy variable in
kexec path", 2019-10-07) is related (part of v5.4), but it's not
sufficient to prevent the boot crash. (That removal only covered the
kexec path, and not the normal boot path.)

> 
> However, once the kernel has booted, any attempt to write to an EFI
> variable results in this:
> 
> [  975.440240] [Firmware Bug]: Page fault caused by firmware at PA: 0x7e450020
> 
> And then the efi runtime gets disabled.

Blech, that doesn't look good. We still get a page fault somewhere in
the firmware, it just doesn't kill the kernel outright. That kind of
suggests the crash on the boot path *is* firmware-originated, it's just
that the kernel is unable to mask the problem that early.

OK, I'll try to look into this more closely... In such cases, I
generally reproduce the guest kernel crash, and while the guest is in
that crashed state, I use

$ virsh dump ovmf.fedora vmcore --memory-only --format kdump-lzo

Then, I force off the VM.

Next, install the "kernel-debuginfo" and "kernel-debuginfo-common"
packages matching the crashed guest kernel.

Finally, run the "crash" utility on the vmcore, to poke around in the
vmcore. "crash" is very powerful, I hope it turns up something...


BTW, the Fedora 5.8.18-100.fc31 kernel does carry like 71 broken-out
extra patches in the SRPM, as far as I can tell...

Thanks
Laszlo


> 
> James
> 
> ---
> 
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 8a26e705cb06..dfae61f07196 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -844,7 +844,7 @@ static void __init __efi_enter_virtual_mode(void)
>  	efi_runtime_update_mappings();
>  
>  	/* clean DUMMY object */
> -	efi_delete_dummy_variable();
> +	//efi_delete_dummy_variable();
>  	return;
>  
>  err:
>