All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Ard Biesheuvel <ardb+git@google.com>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, Borislav Petkov <bp@alien8.de>,
	Kevin Loughlin <kevinloughlin@google.com>
Subject: Re: [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP
Date: Mon, 7 Apr 2025 13:05:01 -0500	[thread overview]
Message-ID: <9f689ba2-add6-cca2-e7b3-fa0393fe2b98@amd.com> (raw)
In-Reply-To: <ldrma6tce2bwhenu5kobjzvk7cz445ubfmpcynwadqudgvzuh3@aibigcdzui6m>

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?

Thanks,
Tom

  parent reply	other threads:[~2025-04-07 18:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04  8:29 [PATCH v2 0/3] efistub/x86: Fix early SEV-SNP memory acceptance Ard Biesheuvel
2025-04-04  8:29 ` [PATCH v2 1/3] x86/boot: Move accept_memory() into decompressor Ard Biesheuvel
2025-04-04  8:29 ` [PATCH v2 2/3] x86/boot: Use separate API for memory acceptance in the EFI stub Ard Biesheuvel
2025-04-04  8:29 ` [PATCH v2 3/3] x86/boot: Implement early memory acceptance for SEV-SNP Ard Biesheuvel
2025-04-04  8:43   ` Kirill A. Shutemov
2025-04-04  8:46     ` Ard Biesheuvel
2025-04-04 15:07       ` Dionna Amalie Glaze
2025-04-07  9:25         ` Kirill A. Shutemov
2025-04-07 16:44           ` Ingo Molnar
2025-04-07 17:21             ` Ard Biesheuvel
2025-04-07 17:33               ` Kirill A. Shutemov
2025-04-07 17:45                 ` Ard Biesheuvel
2025-04-07 21:08                   ` Kirill A. Shutemov
2025-04-07 18:05           ` Tom Lendacky [this message]
2025-04-07 19:59             ` Ard Biesheuvel
2025-04-08 15:53               ` Tom Lendacky
2025-04-10 13:28                 ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f689ba2-add6-cca2-e7b3-fa0393fe2b98@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dionnaglaze@google.com \
    --cc=kevinloughlin@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.