[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXERL=8Y51RUJSqgLWVMs4PJa9aQK0puvKaCpg6eRu0t8g@mail.gmail.com>
Date: Mon, 7 Apr 2025 21:59:48 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Dionna Amalie Glaze <dionnaglaze@...gle.com>, Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, x86@...nel.org, Borislav Petkov <bp@...en8.de>,
Kevin Loughlin <kevinloughlin@...gle.com>
Subject: Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP
On Mon, 7 Apr 2025 at 20:05, Tom Lendacky <thomas.lendacky@....com> wrote:
>
> On 4/7/25 04:25, Kirill A. Shutemov wrote:
> > On Fri, Apr 04, 2025 at 08:07:03AM -0700, Dionna Amalie Glaze wrote:
> >> If the GHCB is available, we should always prefer it.
> >
> > I believe we should consider the cost of code duplication in this
> > situation.
> >
> > If the non-early version is only used in the kexec path, it will not be
> > tested as frequently and could be more easily broken. I think it would be
> > acceptable for kexec to be slightly slower if it results in more
> > maintainable code.
> >
>
> Is accept_memory() in the decompressor or efistub only used in the kexec
> path?
>
The EFI stub does not call accept_memory(), only the decompressor
does. The only use case for explicit memory acceptance in the EFI stub
is process_unaccepted_memory(), which accepts the misaligned chunk of
memory that cannot be described at 2M granularity by the accepted
memory table.
Remember that the EFI stub no longer calls into the legacy
decompressor at all - it decompresses the kernel while executing the
EFI boot services and branches straight to it.
Powered by blists - more mailing lists