Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200409130434.6736-1-ardb@kernel.org> <20200409190109.GB45598@mit.edu>
 <CAMj1kXGiA3PAybR7r9tatL7WV5iU7B1OQxQok3d-JmRnhX1TnA@mail.gmail.com> <20200409201632.GC45598@mit.edu>
In-Reply-To: <20200409201632.GC45598@mit.edu>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Thu, 9 Apr 2020 23:29:06 +0200
Message-ID: <CAMj1kXFqKGSqm_y+ht4mmmu10TrhSyiTG8V3PxRYGodpZ=xNFQ@mail.gmail.com>
Subject: Re: [GIT PULL 0/9] EFI fixes for v5.7-rc
To:     "Theodore Y. Ts'o" <tytso@mit.edu>
Cc:     linux-efi <linux-efi@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Arvind Sankar <nivedita@alum.mit.edu>,
        Borislav Petkov <bp@suse.de>,
        Colin Ian King <colin.king@canonical.com>,
        Gary Lin <glin@suse.com>, Jiri Slaby <jslaby@suse.cz>,
        Sergey Shatunov <me@prok.pw>, Takashi Iwai <tiwai@suse.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 9 Apr 2020 at 22:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> 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?
>

Does this help at all?

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 781170d36f50..52f8138243df 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -180,6 +180,7 @@ extern void __init
efi_uv1_memmap_phys_epilog(pgd_t *save_pgd);

 struct efi_setup_data {
        u64 fw_vendor;
+       u64 __unused;
        u64 tables;
        u64 smbios;
        u64 reserved[8];