public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Min Xu" <min.m.xu@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"kraxel@redhat.com" <kraxel@redhat.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	"James Bottomley" <jejb@linux.ibm.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B
Date: Fri, 24 Dec 2021 03:02:27 +0000	[thread overview]
Message-ID: <PH0PR11MB5064F84910A059F6CEE4D076C57F9@PH0PR11MB5064.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20211220121145.aiqcqs6vd2hb2sb4@sirius.home.kraxel.org>

Hi
> 
> > > Why?  Booting non-tdx guests without PEI shouldn't be fundamentally
> > > different from a TDX guest.  Memory detection needs fw_cfg instead
> > > of the td_hob, and you have to skip some tdx setup steps, but that
> should be it.
> > > Code for all that exists in PlatformPei, it only needs to be moved
> > > to a place where SEC can use it too.
> 
> > We would like to split TDVF Config-B into below stages.
> > 1. Basic Config-B (wave-3)
> > 1.1 A standalone IntelTdxX64.dsc/.fdf. Un-used drivers/libs are removed
> from the fdf, such as network components, SMM drivers, TPM drivers, etc.
> > 1.2 PEI FV is excluded from the build. Only DxeFV is included.
> > 1.3 Since PEI FV is excluded from the build, so Basic Config-B can only bring
> up Tdx guest. It *CAN NOT* bring up legacy guest.
> 
> What blocks legacy guest bringup?
> 
> See above, I think it should not be hard to do, and given that TDX-capable
> hardware is not yet production ready I find it rather important that testing
> the PEI-less boot workflow does not require TDX.
Current PlatformPei does below tasks (no SMM, no S3):
1. Fetch the memory information from either e820 or CMOS, then create the ResourceDescriptorHob.
2. Create MemoryAllocationHob for PeiFV/DxeFV, create FvHob for DxeFV.
3. Read the CPU count from QEMU and set the PCDs.
4. Create the ResourceDescriptorHob for MMIO and set the PCDs
5. Other Hobs, such as MemTypeInfoHob, CpuHob
6. Set PCDs, such as PcdSetNxForStack, PcdOvmfHostBridgePciDevId, PcdPciIoBase, etc
7. Calculate the memory for PEI and PublishPeiMemory
8. InstallClearCacheCallback/InstallFeatureControlCallback

Task 7 is not needed in PEI-less boot up.
Task 8 is not needed either because it is for MP Services.

PCDs cannot be set in SEC phase, so the values should be saved in a Hob (for example, PLATFORM_INFO_HOB). In early DXE phase these values are set to the PCDs. This is how TdxDxe does today.

Other tasks can be done in SEC phase. I think there should be a lib (for example, PlatformPeiLib) to wrap these functions so that they can be re-used by OvmfPkg/PlatformPei. 

PEI-less booting up legacy guest doesn't support TPM.

So to boot up legacy guest without PEI phase, there will be below changes.
1. OvmfStartupLib:  (like TdxStartupLib)
    - Decompress DxeFv, locate DxeCore, create IdentityMappingPageTables, then jump to DxeCore.
2. PlatformPeiLib:
    - Wrap the functions to do memory initialization, etc. (see tasks 1-5)
3. OvmfLegacyDxe
    - Set the PCDs (see task 6)

Base upon above consideration, It's a big change. That's why we suggest implement Config-B in 3 stages.

I am also thinking about another option which includes PEI in build. (That's Config-B v1)
In this option, Ovmf image layout is kept unchanged. In run-time Tdx guest is probed. If it is Tdx guest, it goes to TdxStartup and brings up Tdx guest. Otherwise it follows normal Ovmf boot flow.
The advantages are:
1. The change is small.
2. It doesn't impact the current legacy guest, nor the SEV guest.

I know there are many discussions in above options. Can we follow below road map so that we can discuss 3 (How to achieve ONE Binary) in more details?
1. Basic Config-B (PEI-less and only Tdx guest)
2. Advanced Config-B (RTMR based measurement)
3. One Binary Config-B (support legacy guest)

> ... and given that TDX-capable
> hardware is not yet production ready I find it rather important that testing
> the PEI-less boot workflow does not require TDX.
> 
> It'll also make it much easier to add CI coverage.
I am thinking if SEV features are covered in CI? Because I want to make sure our changes don't impact SEV.

Thanks
Min

  reply	other threads:[~2021-12-24  3:02 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 13:41 [PATCH 00/10] Introduce TDVF Config-B (basic) in OvmfPkg Min Xu
2021-12-14 13:41 ` [PATCH 01/10] OvmfPkg: Introduce IntelTdxX64 for TDVF Config-B Min Xu
2021-12-15  9:32   ` Gerd Hoffmann
2021-12-14 13:41 ` [PATCH 02/10] EmbeddedPkg/PrePiLib: Update PrePiLib Min Xu
2021-12-14 14:00   ` [edk2-devel] " Ard Biesheuvel
2021-12-16  4:48     ` Min Xu
2021-12-14 13:41 ` [PATCH 03/10] EmbeddedPkg/MemoryAllocationLib: Add null stub for AllocateCopyPool Min Xu
2021-12-14 13:59   ` [edk2-devel] " Ard Biesheuvel
2021-12-16  3:08     ` Min Xu
2021-12-14 13:41 ` [PATCH 04/10] OvmfPkg: Add PrePiHobListPointerLibTdx Min Xu
2021-12-14 13:41 ` [PATCH 05/10] OvmfPkg: Add SecPlatformLibQemuTdx Min Xu
2021-12-15  9:48   ` Gerd Hoffmann
2022-01-07  6:29     ` Min Xu
2021-12-14 13:41 ` [PATCH 06/10] OvmfPkg: Add TdxStartupLib Min Xu
2021-12-15 10:09   ` Gerd Hoffmann
2021-12-16 11:56     ` Min Xu
2022-01-12  1:55       ` Min Xu
2021-12-14 13:41 ` [PATCH 07/10] OvmfPkg: Update TdxDxe to set TDX PCDs Min Xu
2021-12-14 13:41 ` [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B Min Xu
2021-12-15 10:27   ` Gerd Hoffmann
2021-12-16 12:21     ` [edk2-devel] " Min Xu
2021-12-16 14:25       ` Gerd Hoffmann
2021-12-19  2:49         ` Min Xu
2021-12-20 12:11           ` Gerd Hoffmann
2021-12-24  3:02             ` Min Xu [this message]
2022-01-03  8:02               ` Gerd Hoffmann
2022-01-07  6:13                 ` Min Xu
2022-01-10  7:55                   ` Gerd Hoffmann
2022-01-11  2:24                     ` Min Xu
2022-01-11  9:23                       ` Gerd Hoffmann
2022-01-14  2:17                         ` Min Xu
2022-01-14  8:32                           ` Gerd Hoffmann
2022-01-16  0:55                             ` Min Xu
2021-12-14 13:41 ` [PATCH 09/10] OvmfPkg: Update DxeAcpiTimerLib to read HostBridgeDevId in PlatformInfoHob Min Xu
2021-12-14 13:41 ` [PATCH 10/10] OvmfPkg: Add Tdx libs to prevent building broken Min Xu
2021-12-15 10:41 ` [PATCH 00/10] Introduce TDVF Config-B (basic) in OvmfPkg Gerd Hoffmann
2021-12-16 12:36   ` 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=PH0PR11MB5064F84910A059F6CEE4D076C57F9@PH0PR11MB5064.namprd11.prod.outlook.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