public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io, dave.hansen@intel.com
Cc: dionnaglaze@google.com, dave.hansen@linux.intel.com,
	Jiewen <jiewen.yao@intel.com>,
	"Shutemov, Kirill" <kirill.shutemov@intel.com>
Subject: Re: [edk2-devel] [PATCH v9 0/4] Add safe unaccepted memory behavior
Date: Mon, 16 Jan 2023 11:28:01 +0100	[thread overview]
Message-ID: <20230116102801.y3l6xn3gdgregn4k@sirius.home.kraxel.org> (raw)
In-Reply-To: <d2ff3032-5fa6-7d3e-67f0-ce0d7a9a7fdd@intel.com>

On Fri, Jan 13, 2023 at 10:34:15AM -0800, Dave Hansen wrote:
> On 1/13/23 10:23, Dionna Glaze via groups.io wrote:
> >> However, *NONE* of this points me in the direction of saying that we
> >> should have an OS/firmware protocol to negotiate whether the firmware or
> >> OS does page acceptance other than the existing UEFI memory map bit.
> > We know of distributions that are going to release SEV-SNP support
> > without unaccepted memory support,
> 
> Well, I guess that's a bit of a different problem.
> 
> I'd love to hear from the distros what they're planning on carrying
> outside of mainline and what their plans are for the kernel side of this
> series.

Fedora has near zero additional patches, so it pretty much depends on
how mainline merges stuff.  If SEV-SNP or TDX or both will land in an
upstream release before support for unaccepted memory lands too you'll
see that in Fedora kernels, and I guess likewise in most non-enterprise
distros.

RHEL/CentOS typically requires mainline acceptance too for backports, so
it likewise depends on upstream merging, and additionally rhel release
planning comes into play.  In case unaccepted memory support lands later
than TDX it could (depending on timing) very well be that the choices
are to either backport TDX without unaccepted memory support, or move
both TDX support and unaccepted memory support to a later release.

take care,
  Gerd


  reply	other threads:[~2023-01-16 10:28 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13  0:14 [PATCH v9 0/4] Add safe unaccepted memory behavior Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 1/4] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 2/4] MdePkg: Introduce the MemoryAcceptance protocol Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 3/4] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2023-01-13  0:14 ` [PATCH v9 4/4] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze
2023-01-13  3:46 ` [PATCH v9 0/4] Add safe unaccepted memory behavior Yao, Jiewen
2023-01-13  7:18   ` [edk2-devel] " Gerd Hoffmann
2023-01-13  7:32     ` Yao, Jiewen
2023-01-13  9:32       ` Ard Biesheuvel
2023-01-13 11:11         ` Yao, Jiewen
2023-01-13 11:24           ` Ard Biesheuvel
2023-01-13 11:44             ` Yao, Jiewen
2023-01-13 12:00               ` Ard Biesheuvel
2023-01-13 16:00               ` dave.hansen
2023-01-13 17:06                 ` Dionna Glaze
2023-01-13 17:57                   ` Dave Hansen
2023-01-13 18:23                     ` Dionna Glaze
2023-01-13 18:34                       ` Dave Hansen
2023-01-16 10:28                         ` Gerd Hoffmann [this message]
2023-01-24 22:42                           ` Lendacky, Thomas
2023-01-24 22:46                             ` Dave Hansen
2023-01-25  9:01                             ` Ard Biesheuvel
2023-01-25  9:18                               ` Gerd Hoffmann
2023-01-25 11:44                                 ` Ard Biesheuvel
2023-01-25 12:10                                   ` Gerd Hoffmann
2023-01-25 14:52                                     ` Ard Biesheuvel
2023-01-25 16:56                                       ` Yao, Jiewen

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-list 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=20230116102801.y3l6xn3gdgregn4k@sirius.home.kraxel.org \
    --to=devel@edk2.groups.io \
    /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