From: "Laszlo Ersek" <lersek@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"erdemaktas@google.com" <erdemaktas@google.com>,
"cho@microsoft.com" <cho@microsoft.com>,
"bret.barkelew@microsoft.com" <bret.barkelew@microsoft.com>,
Jon Lange <jlange@microsoft.com>, Karen Noel <knoel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Nathaniel McCallum <npmccallum@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Ademar de Souza Reis Jr." <areis@redhat.com>
Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF
Date: Tue, 8 Jun 2021 17:36:54 +0200 [thread overview]
Message-ID: <a6d3a5d6-a880-07e1-505a-d5e073eac451@redhat.com> (raw)
In-Reply-To: <PH0PR11MB50649131AF6826AC8823D731C5379@PH0PR11MB5064.namprd11.prod.outlook.com>
On 06/08/21 14:27, Xu, Min M wrote:
> On 06/04/2021 12:12 AM, Laszlo wrote:
>> But it counts as an absolute disaster nowadays, and should not be revived in
>> any platform. If you don't have pflash in TDX guests, just accept that you
>> won't have non-volatile variables. And link PlatformFvbLibNull into
>> EmuVariableFvbRuntimeDxe. You're going to need a separate
>> PlatformBootManagerLib instance anyway.
>>
> I have a question here, that if PlatformFvbLibNull is linked into EmuVaiableFvRuntimeDxe,
> Does it mean it cannot write to the in-RAM variable store?
No, that's not the case; PlatformFvbLibNull only turns the hooks
(special callbacks) into no-ops; the normal operation of
EmuVariableFvbRuntimeDxe is not disrupted.
The APIs in the PlatformFvbLib class are PlatformFvbDataRead,
PlatformFvbDataWritten, PlatformFvbBlocksErased; they are called at the
ends of the functions FvbProtocolEraseBlocks(), FvbProtocolWrite(),
FvbProtocolRead(), in "OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c". If the
PlatformFvb* APIs do nothing, that's not a problem for
EmuVariableFvbRuntimeDxe.
(In fact, even in the non-Null instance -- that is, in the
EmuVariableFvbLib instance --, the read and erase callbacks are empty;
and the write callback only signals an event, at best.)
>> (We should have removed EmuVariableFvbRuntimeDxe a long time ago from
>> the traditional OVMF platforms, i.e. made pflash a hard requirement, even
>> when SMM is not built into the platform -- but whenever I tried that, Jordan
>> always shot me down.)
>>
> I am afraid in TDVF we have to use EmuVariableFvRuntimeDxe to emulate the
> in-RAM, as I explained pflash is not part of the *board* in TDX setup.
Using EmuVariableFvbRuntimeDxe in the TDVF platform is fine (with the
Null hooks, see above), as long as we carefully document the expected /
resultant behavior of the UEFI variable services.
(This is not a comment on my part on the SB situation, which remains an
open question for TDVF, for the time being.)
Thanks
Laszlo
next prev parent reply other threads:[~2021-06-08 15:37 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-03 13:51 [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Yao, Jiewen
2021-06-03 16:11 ` Laszlo Ersek
2021-06-03 23:19 ` Yao, Jiewen
2021-06-04 10:11 ` Laszlo Ersek
2021-06-04 10:24 ` Yao, Jiewen
2021-06-04 10:43 ` Michael Brown
2021-06-04 14:52 ` Michael Brown
2021-06-04 15:04 ` James Bottomley
2021-06-04 7:33 ` Min Xu
2021-06-06 2:03 ` Min Xu
2021-06-06 11:29 ` Michael Brown
2021-06-06 12:49 ` Min Xu
2021-06-07 13:52 ` Laszlo Ersek
2021-06-06 8:52 ` Min Xu
2021-06-06 11:39 ` Michael Brown
2021-06-08 12:27 ` Min Xu
2021-06-08 15:36 ` Laszlo Ersek [this message]
2021-06-08 16:01 ` James Bottomley
2021-06-08 19:33 ` Laszlo Ersek
2021-06-09 0:58 ` Min Xu
2021-06-09 11:00 ` Laszlo Ersek
2021-06-09 14:36 ` James Bottomley
2021-06-09 2:01 ` Min Xu
2021-06-09 14:28 ` James Bottomley
2021-06-09 15:47 ` Paolo Bonzini
2021-06-09 15:59 ` James Bottomley
2021-06-10 21:01 ` Erdem Aktas
2021-06-10 22:30 ` Min Xu
2021-06-11 1:33 ` James Bottomley
2021-06-11 1:36 ` Yao, Jiewen
2021-06-11 1:38 ` James Bottomley
2021-06-11 1:55 ` James Bottomley
[not found] ` <168759329436FBCF.5845@groups.io>
2021-06-11 6:37 ` Min Xu
2021-06-22 13:34 ` Laszlo Ersek
2021-06-22 13:38 ` Laszlo Ersek
2021-06-24 0:24 ` Min Xu
2021-06-24 0:35 ` James Bottomley
2021-06-24 0:55 ` Min Xu
[not found] ` <168B5EA81BA66FAC.7570@groups.io>
2021-07-01 5:00 ` Min Xu
2021-06-23 2:44 ` Min Xu
2021-06-23 17:47 ` Laszlo Ersek
2021-06-23 11:56 ` Min Xu
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=a6d3a5d6-a880-07e1-505a-d5e073eac451@redhat.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