From: "Dionna Glaze" <dionnaglaze@google.com>
To: "Ni, Ray" <ray.ni@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
Ard Biescheuvel <ardb@kernel.org>,
"Xu, Min M" <min.m.xu@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
James Bottomley <jejb@linux.ibm.com>,
Tom Lendacky <Thomas.Lendacky@amd.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"Aktas, Erdem" <erdemaktas@google.com>,
Andrew Fish <afish@apple.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH v7 0/7] Add safe unaccepted memory behavior
Date: Fri, 14 Oct 2022 14:29:58 -0700 [thread overview]
Message-ID: <CAAH4kHYhCgqT+WW_echr=kuD9ZMXU9cWfeW1DiFHfAtvM5CpnQ@mail.gmail.com> (raw)
In-Reply-To: <MWHPR11MB1631D7576710A4F755BDFC478C249@MWHPR11MB1631.namprd11.prod.outlook.com>
>
> Can OsIndicationsSupported UEFI variable provide the similar functionality?
>
Similar, but not the same. If we use a UEFI variable, its value will
persist across boots. This can be fine if you only boot one OS, but if
you have two where one supports unaccepted memory and the other
doesn't then you have a problem.
The protocol here is specific to the code that will be calling
ExitBootServices, and thus won't mess up another OS once we reboot and
select it.
--
-Dionna Glaze, PhD (she/her)
next prev parent reply other threads:[~2022-10-14 21:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-05 20:33 [PATCH v7 0/7] Add safe unaccepted memory behavior Dionna Glaze
2022-10-05 20:33 ` [PATCH v7 1/7] OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxe Dionna Glaze
2022-10-05 20:43 ` Lendacky, Thomas
2022-10-05 20:33 ` [PATCH v7 2/7] MdePkg: Add EFI_EVENT_BEFORE_EXIT_BOOT_SERVICES_GUID Dionna Glaze
2022-10-06 12:45 ` Ard Biesheuvel
2022-10-10 1:33 ` 回复: [edk2-devel] " gaoliming
2022-10-05 20:33 ` [PATCH v7 3/7] MdeModulePkg: Notify BeforeExitBootServices in CoreExitBootServices Dionna Glaze
2022-10-05 20:50 ` Lendacky, Thomas
2022-10-05 20:58 ` Dionna Glaze
2022-10-10 1:32 ` 回复: [edk2-devel] " gaoliming
[not found] ` <171B47E3227F0BCA.23411@groups.io>
2022-10-05 21:01 ` Dionna Glaze
2022-10-06 12:46 ` Ard Biesheuvel
2022-10-05 20:33 ` [PATCH v7 4/7] OvmfPkg: Introduce CocoDxe driver Dionna Glaze
2022-10-05 20:33 ` [PATCH v7 5/7] MdePkg: Introduce the AcceptAllUnacceptedMemory protocol Dionna Glaze
2022-10-05 20:33 ` [PATCH v7 6/7] OvmfPkg: Implement AcceptAllUnacceptedMemory in CocoDxe Dionna Glaze
2022-10-05 20:33 ` [PATCH v7 7/7] OvmfPkg/PlatformPei: SEV-SNP make >=4GB unaccepted Dionna Glaze
2022-10-05 21:02 ` Lendacky, Thomas
2022-10-14 6:20 ` [edk2-devel] [PATCH v7 0/7] Add safe unaccepted memory behavior Ni, Ray
2022-10-14 21:29 ` Dionna Glaze [this message]
2022-10-19 8:57 ` Ard Biesheuvel
2022-10-20 22:37 ` Dionna Glaze
2022-10-21 13:17 ` Ard Biesheuvel
2022-10-21 15:42 ` Dionna Glaze
2022-10-24 8:34 ` aik
2022-10-24 15:24 ` Dionna Glaze
2022-10-26 0:23 ` aik
2022-10-26 1:07 ` Dionna Glaze
2022-10-26 1:35 ` Alexey Kardashevskiy
2022-10-26 2:49 ` Alexey Kardashevskiy
2022-10-27 3:18 ` Alexey Kardashevskiy
2022-10-27 15:38 ` Dionna Glaze
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='CAAH4kHYhCgqT+WW_echr=kuD9ZMXU9cWfeW1DiFHfAtvM5CpnQ@mail.gmail.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