public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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