From: "Ni, Ray" <ray.ni@intel.com>
To: Min Xu <min.m.xu@intel.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg: Save PcdConfidentialComputingGuestAttr in mCcGuestAttr
Date: Wed, 04 May 2022 18:41:02 -0700 [thread overview]
Message-ID: <21893.1651714862231437175@groups.io> (raw)
In-Reply-To: <PH0PR11MB5064B275A7AA3BDF6C7959E6C5C19@PH0PR11MB5064.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]
On Mon, May 2, 2022 at 03:03 PM, Min Xu wrote:
>
> The reason why C global variable cannot be used in PEIM is that in some
> scenario PEIM is executed in FLASH so that the value of C global variable
> cannot be kept in different calls. But I don't think it is a problem in this
> situation.
> 1. This global variable is to keep the PcdConfidentialComputingGuestAttribute
> in mCcGuestAttr. So if this is Tdx guest, then the global variable can be kept
> (CC_GUEST_IS_TDX (mCcGuestAttr) == TRUE).
> 2. If this is Non-Td guest, then even the global variable cannot be kept,
> CC_GUEST_IS_TDX (mCcGuestAttr) is FALSE. So mCcGuestAttr can still work.
Directly writing to flash area might cause some side effects.
Usually we need to avoid that.
>
> There is another solution that we can use CcProbe (which is in
> MdePkg/CcProbeLib). CcProbe checks the work area to fetch the guest type. It
> calls FixedPcdGet32 (PcdOvmfWorkAreaBase) so there is no SMP safe issue in
> PcdLib.
It seems ok. But it's unclear to me how the work area is built.
>
> As to a new field in CPU_MP_DATA, Tdx guest doesn't create CPU_MP_DATA object
> in MpInitLibInitialize, instead it return right after it detects the working
> guest is Tdx guest. So this fix will be more complicated than above 2
> solutions.
I agree it'll be more complicated to let the TDX version of MpLib use the CPU_MP_DATA.
But, I am very curious why not leave the MpInitLib untouched. The solution is:
1. Platform FDF includes two CpuMpPeim drivers. One links to PeiMpInitLib, the other links to MpInitLibUp.
Change platform DSC to let first PEIM depend on "FullMpPpi"
Change platform DSC to let second PEIM depend on "UpMpPpi"
2. SEC code passes "FullMpPpi" to PEI Core when it's not a TDX boot. It passes "UpMpPpi" when it's a TDX boot.
I think this solution doesn't even change the MP code. Or saying in another way, MP and TDX are decoupled.
I prefer this solution.
>
> Ray, What's your thought?
>
[-- Attachment #2: Type: text/html, Size: 2177 bytes --]
next prev parent reply other threads:[~2022-05-05 1:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1651201263.git.min.m.xu@intel.com>
2022-04-29 3:02 ` [PATCH 1/1] UefiCpuPkg: Save PcdConfidentialComputingGuestAttr in mCcGuestAttr Min Xu
2022-04-29 3:06 ` Ni, Ray
2022-05-02 7:03 ` Min Xu
2022-05-05 1:41 ` Ni, Ray [this message]
2022-05-05 14:30 ` [edk2-devel] " 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=21893.1651714862231437175@groups.io \
--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