From: "Lendacky, Thomas" <thomas.lendacky@amd.com>
To: Dave Hansen <dave.hansen@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Dionna Glaze <dionnaglaze@google.com>,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
x86@kernel.org, jiewen.yao@intel.com, devel@edk2.groups.io,
Ard Biescheuvel <ardb@kernel.org>,
"Min M. Xu" <min.m.xu@intel.org>,
James Bottomley <jejb@linux.ibm.com>,
Erdem Aktas <erdemaktas@google.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI
Date: Mon, 16 Jan 2023 16:46:32 -0600 [thread overview]
Message-ID: <1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com> (raw)
In-Reply-To: <def9b0b5-b880-be99-fa95-b05d76a91824@intel.com>
On 1/16/23 15:22, Dave Hansen wrote:
> On 1/16/23 02:56, Gerd Hoffmann wrote:
>>> And we add this protocol to address very temporary problem: once
>>> unaccepted memory support get upstream it is just a dead weight.
>> Maybe, maybe not. unaccepted memory support has a Kconfig switch after
>> all. If we figure in 3-5 years that all distros have enabled it anyway
>> we can drop it again. For the transition period it will surely be
>> useful.
>
> I agree with Kirill here.
>
> Having unaccepted memory *AND* this firmware-driven feature really is
> just implementing the same thing twice.
I'm not sure I follow you. This feature merely tells the firmware whether
or not the OS supports unaccepted memory, which then tells the firmware
whether it needs to accept the memory or whether the kernel can.
We have had SNP guest support since 5.19 without support for unaccepted
memory. Imagine now using a newer OVMF that can support unaccepted memory.
How does the firmware know whether it must accept all the memory or
whether it can advertise unaccepted memory. By having the kernel call this
boot service protocol once support for unaccepted memory is in place, the
firmware now knows that it need not accept all the memory.
Thanks,
Tom
>
> I'd much rather have the Kconfig option forced on for all guests that
> *might* need unaccepted memory support than carry redundant implementations.
>
> Also, _if_ we allow folks to turn the Kconfig off and get access to all
> their memory, they might get used to that. Removing this firmware
> interface from the kernel in a few years could be viewed as a
> regression. Then, we'll be stuck with this forever.
>
> In any case, the firmware side of things didn't seem like _that_ much
> code. So, I'm not protesting *that* strongly. But, I also don't
> believe for a second that this is going to be removed in 3-5 years.
next prev parent reply other threads:[~2023-01-16 22:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 21:29 [PATCH v2] x86/efi: Safely enable unaccepted memory in UEFI Dionna Glaze
2023-01-13 22:20 ` Kirill A. Shutemov
2023-01-16 10:56 ` Gerd Hoffmann
2023-01-16 12:30 ` Kirill A. Shutemov
2023-01-16 13:11 ` Ard Biesheuvel
2023-01-16 13:42 ` Kirill A. Shutemov
2023-01-16 19:43 ` Dionna Glaze
2023-01-16 23:17 ` Kirill A. Shutemov
2023-01-17 10:24 ` Gerd Hoffmann
2023-01-17 16:45 ` Dionna Glaze
2023-01-18 7:51 ` [edk2-devel] " Gerd Hoffmann
2023-01-16 21:22 ` Dave Hansen
2023-01-16 22:46 ` Lendacky, Thomas [this message]
2023-01-18 15:09 ` Ard Biesheuvel
2023-01-18 15:40 ` Dave Hansen
2023-01-18 15:46 ` Ard Biesheuvel
2023-01-17 10:34 ` 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-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=1818a72f-31ef-07b0-d1b4-6a8904636db2@amd.com \
--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