All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>,
	Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Michael Roth <michael.roth@amd.com>,
	Joerg Roedel <jroedel@suse.de>,
	Dionna Glaze <dionnaglaze@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ard Biescheuvel <ardb@kernel.org>,
	"Min M. Xu" <min.m.xu@intel.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Erdem Aktas <erdemaktas@google.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v7 6/6] x86/efi: Safely enable unaccepted memory in UEFI
Date: Tue, 4 Apr 2023 10:57:52 -0700	[thread overview]
Message-ID: <bc9e6d82-c7c1-47dc-e91f-57d9b4e2bb0a@intel.com> (raw)
In-Reply-To: <20230404174506.pjdikxvk2fsyy4au@box.shutemov.name>

On 4/4/23 10:45, Kirill A. Shutemov wrote:
> I still think it is a bad idea.
> 
> As I asked before, please include my
> 
> Nacked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> 
> into the patch.

I was pretty opposed to this when I first saw it too.  But, Tom and
company have worn down my opposition a bit.

The fact is that we have upstream kernels out there with SEV-SNP support
that don't know anything about unaccepted memory.  They're either
relegated to using the pre-accepted memory (4GB??) or _some_ entity
needs to accept the memory.  That entity obviously can't be the kernel
unless we backport unaccepted memory support.

This both lets the BIOS be the page-accepting entity _and_ allows the
entity to delegate that to the kernel when it needs to.

As much as I want to nak this and pretend that that those existing
kernel's don't exist, my powers of self-delusion do have their limits.

If our AMD friends don't do this, what is their alternative?

  reply	other threads:[~2023-04-04 17:57 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30 11:49 [PATCHv9 00/14] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 01/14] x86/boot: Centralize __pa()/__va() definitions Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 02/14] mm: Add support for unaccepted memory Kirill A. Shutemov
2023-04-03  9:26   ` Vlastimil Babka
2023-04-03 10:02     ` Kirill A. Shutemov
2023-04-03 13:07       ` Vlastimil Babka
2023-03-30 11:49 ` [PATCHv9 03/14] mm/page_alloc: Fake " Kirill A. Shutemov
2023-04-03 13:39   ` Vlastimil Babka
2023-04-03 14:39     ` Kirill A. Shutemov
2023-04-03 15:50       ` Kirill A. Shutemov
2023-04-14 10:19         ` Kirill A. Shutemov
2023-04-03 14:43   ` David Hildenbrand
2023-04-03 14:47     ` Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 04/14] mm/page_alloc: Add sysfs handle to accept accept_memory Kirill A. Shutemov
2023-04-03 13:43   ` Vlastimil Babka
2023-04-03 14:41     ` Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 05/14] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 06/14] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 07/14] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 08/14] x86/boot/compressed: Handle " Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 09/14] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 10/14] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 11/14] x86/mm: Avoid load_unaligned_zeropad() stepping into " Kirill A. Shutemov
2023-04-03 13:28   ` Vlastimil Babka
2023-04-03 14:42     ` Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 12/14] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 13/14] x86/tdx: Refactor try_accept_one() Kirill A. Shutemov
2023-03-30 11:49 ` [PATCHv9 14/14] x86/tdx: Add unaccepted memory support Kirill A. Shutemov
2023-04-03 14:42 ` [PATCHv9 00/14] mm, x86/cc: Implement support for unaccepted memory Vlastimil Babka
2023-04-16 19:19   ` Kirill A. Shutemov
2023-04-17  7:37     ` Vlastimil Babka
2023-04-04 17:23 ` [PATCH v7 0/6] Provide SEV-SNP " Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 1/6] x86/sev: Fix calculation of end address based on number of pages Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 2/6] x86/sev: Put PSC struct on the stack in prep for unaccepted memory support Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 3/6] x86/sev: Allow for use of the early boot GHCB for PSC requests Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 4/6] x86/sev: Use large PSC requests if applicable Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 5/6] x86/sev: Add SNP-specific unaccepted memory support Tom Lendacky
2023-04-04 17:23   ` [PATCH v7 6/6] x86/efi: Safely enable unaccepted memory in UEFI Tom Lendacky
2023-04-04 17:45     ` Kirill A. Shutemov
2023-04-04 17:57       ` Dave Hansen [this message]
2023-04-04 18:09         ` Kirill A. Shutemov
2023-04-04 19:27           ` Dave Hansen
2023-04-04 19:49           ` Ard Biesheuvel
2023-04-04 20:24             ` Kirill A. Shutemov
2023-04-04 20:41               ` Ard Biesheuvel
2023-04-04 21:01                 ` Kirill A. Shutemov
2023-04-05  7:46                   ` Ard Biesheuvel
2023-04-05 13:00                     ` Dave Hansen
2023-04-05 13:44                       ` Ard Biesheuvel
2023-04-05 16:15                         ` Dave Hansen
2023-04-05 19:06                           ` Kirill A. Shutemov
2023-04-05 20:11                             ` Tom Lendacky
2023-04-05 21:22                               ` Dave Hansen
2023-04-05 21:34                                 ` Ard Biesheuvel
2023-04-05 13:42                     ` Kirill A. Shutemov
2023-04-05 13:51                       ` Ard Biesheuvel
2023-04-05 10:06                   ` Gerd Hoffmann

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=bc9e6d82-c7c1-47dc-e91f-57d9b4e2bb0a@intel.com \
    --to=dave.hansen@intel.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=erdemaktas@google.com \
    --cc=hpa@zytor.com \
    --cc=jejb@linux.ibm.com \
    --cc=jiewen.yao@intel.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=min.m.xu@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --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.