public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	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>,
	"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: Wed, 5 Apr 2023 06:00:46 -0700	[thread overview]
Message-ID: <e46777d3-adea-90a2-afc4-35f9d7cef50c@intel.com> (raw)
In-Reply-To: <CAMj1kXGvcg-E84h1T_vPi7qxPWxEXBpyuB79KOL+ON7v5YAgJg@mail.gmail.com>

On 4/5/23 00:46, Ard Biesheuvel wrote:
> Once the firmware stops exposing this protocol (and ceases to accept
> memory on the OS's behalf), we can phase it out from the kernel as
> well.

This is a part of the story that I have doubts about.

How and when do you think this phase-out would happen, realistically?

The firmware will need the unaccepted memory protocol support as long as
there are guests around that need it, right?

People like to keep running old kernels for a _long_ time.  Doesn't that
mean _some_ firmware will need to keep doing this dance for a long time?

As long as there is firmware out there in the wild that people want to
run new kernels on, the support needs to stay in mainline.  It can't be
dropped.

  reply	other threads:[~2023-04-05 13:02 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
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 [this message]
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=e46777d3-adea-90a2-afc4-35f9d7cef50c@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox