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
