Re: [GIT PULL 0/9] EFI fixes for v5.7-rc

[Theodore Y. Ts'o]

On Thu, Apr 09, 2020 at 09:04:42PM +0200, Ard Biesheuvel wrote:
> 
> > I'm currently building Linus's latest branch to see if it's been fixed
> > since v5.6-11114-g9c94b39560c3 (which is where I first noticed it) and
> > while I was waiting for v5.6-12349-g87ebc45d2d32 to finish building so
> > I could test it, I noticed these patches, and so I figured I'd fire
> > off this quick question.
> >
> 
> I think we might be able to downright revert that patch if the
> underlying assumption on my part is inaccurate, which was that the
> fact that the boot code no longer uses the runtime table address
> implies that there is no longer a reason to pass it.

Unfortunately, it doesn't cleanly revert, which is why I started
checking to see if it might be fixed already before trying to figure
out how to do a manual revert.  I just tested and the tip of Linus's
tree still has the failure.

The short description of the failure: I'm using Debian Stable (Buster)
with a 4.19 distro kernel and kexec-tools 2.0.18 to kexec into the
kernel under test.  I'm using a Google Compute Engine VM, and the
actual kexec command is here:

https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/usr/local/lib/gce-kexec#L146

What happens is that the kexec'ed kernel immediately crashes, at which
point we drop back into the BIOS, and then it boots the Debain 4.19.0
distro kernel instead of the kernel to be tested boot.  Since we lose
the boot command line that was used from the kexec, the gce-xfstests
image retries the kexec, which fails, and the failing kexec repeats
until I manually kill the VM.

The bisect fingred v5.6-rc1-59-g0a67361dcdaa ("efi/x86: Remove runtime
table address from kexec EFI setup data") as the first failing commit.
Its immediate parent commit, v5.6-rc1-58-g06c0bd93434c works just
fine.

Is there any further debugging information that would be useful?

Thanks,

						- Ted