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>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
	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 09:15:15 -0700	[thread overview]
Message-ID: <969a3d2a-52e7-e60e-5de6-c550c548730d@intel.com> (raw)
In-Reply-To: <CAMj1kXEDYa5YcRj7t9JJmQ21+ierue2q6ADOXUOMjoOGndGRug@mail.gmail.com>

On 4/5/23 06:44, Ard Biesheuvel wrote:
> Given that the intent here is to retain compatibility with
> unenlightened workloads (i.e., which do not upgrade their kernels), I
> think it is perfectly reasonable to drop this from mainline at some
> point.

OK, so there are three firmware types that matter:

1. Today's SEV-SNP deployed firmware.
2. Near future SEV-SNP firmware that exposes the new ExitBootServices()
   protocol that allows guests that speak the protocol to boot faster
   by participating in the unaccepted memory dance.
3. Far future firmware that doesn't have the ExitBootServices() protocol

There are also three kernel types:
1. Old kernels with zero unaccepted memory support: no
   ExitBootServices() protocol support and no hypercalls to accept pages
2. Kernels that can accept pages and twiddle the ExitBootServices() flag
3. Future kernels that can accept pages, but have had ExitBootServices()
   support removed.

That leads to nine possible mix-and-match firmware/kernel combos.  I'm
personally assuming that folks are going to *try* to run with all of
these combos and will send us kernel folks bug reports if they see
regressions.  Let's just enumerate all of them and their implications
before we go consult our crystal balls about what folks will actually do
in the future.

So, here we go:

              |                   Kernel                   |
              |                                            |
              | Unenlightened | Enlightened | Dropped UEFI |
Firmware      |     ~5.19??   |    ~6.4??   | protocol     |
              |---------------+-------------+--------------|
Deployed      |   Slow boot   |  Slow boot  |  Slow boot   |
Near future   |   Slow boot   |  Fast boot  |  Slow boot   |
Far future    |   Crashes??   |  Fast Boot  |  Fast boot   |

I hope I got that all right.

The thing that worries me is the "Near future firmware" where someone
runs a ~6.4 kernel and has a fast boot experience.  They upgrade to a
newer, "dropped protocol" kernel and their boot gets slower.

I'm also a little fuzzy about what an ancient enlightened kernel would
do on a "far future" firmware that requires unaccepted memory support.
I _think_ those kernels would hit some unaccepted memory, and
#VC/#VE/#whatever and die.  Is that right, or is there some fallback there?

  reply	other threads:[~2023-04-05 16:16 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
2023-04-05 13:44                       ` Ard Biesheuvel
2023-04-05 16:15                         ` Dave Hansen [this message]
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=969a3d2a-52e7-e60e-5de6-c550c548730d@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