Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 7 Jul 2023 12:23:59 +0800
From:   Baoquan He <bhe@redhat.com>
To:     Tao Liu <ltao@redhat.com>, jroedel@suse.de, thomas.lendacky@amd.com
Cc:     Borislav Petkov <bp@alien8.de>, tglx@linutronix.de,
        mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org,
        hpa@zytor.com, ardb@kernel.org, linux-kernel@vger.kernel.org,
        dyoung@redhat.com, kexec@lists.infradead.org,
        linux-efi@vger.kernel.org, michael.roth@amd.com
Subject: Re: [PATCH v2] x86/kexec: Add EFI config table identity mapping for
 kexec kernel
Message-ID: <ZKeTX2aemPbsMiVr@MiWiFi-R3L-srv>
References: <20230601072043.24439-1-ltao@redhat.com>
 <20230705173359.GDZKWphyFbNE8id6Jm@fat_crate.local>
 <CAO7dBbXdJgpO4Ym=4WME3OOrUhq2MNKpNZmhpsC7pOSugHiKDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAO7dBbXdJgpO4Ym=4WME3OOrUhq2MNKpNZmhpsC7pOSugHiKDg@mail.gmail.com>
Precedence: bulk

On 07/07/23 at 11:38am, Tao Liu wrote:
> Hi Borislav,
> 
> Thanks for the patch review!
> 
> On Thu, Jul 6, 2023 at 1:34 AM Borislav Petkov <bp@alien8.de> wrote:
> >
> > On Thu, Jun 01, 2023 at 03:20:44PM +0800, Tao Liu wrote:
> > > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
> >
> > s/cpu/CPU/g
> >
> > > EFI config table.
> > >
> > > Currently EFI system table is identity-mapped for the kexec kernel, but EFI
> > > config table is not mapped explicitly:
> >
> > Why does the EFI config table *need* to be mapped explicitly?
> >
> > >     commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and ACPI
> > >                           tables to the ident map")
> > >
> > > Later in the following 2 commits, EFI config table will be accessed when
> > > enabling sev at kernel startup.
> >
> > What does SEV have to do with an Intel problem?
> 
> For the 2 questions above. The call stack is follows:
> 
> head_64.S:.Lon_kernel_cs(which is before extract_kernel) -> sev_enable
> -> snp_init -> find_cc_blob -> find_cc_blob_efi. No matter what cpu,
> with CONFIG_AMD_MEM_ENCRYPT enabled, all will enter sev_enable() and
> go through these functions. I assume it is harmless for Intel cpu,

I am wondering why we don't detect the cpu type and return early inside
sev_enable() if it's Intel cpu.

We can't rely on CONFIG_AMD_MEM_ENCRYPT to decide if the code need be
executed or not because we usually enable them all in distros.

Thanks
Baoquan