public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Leo Duran <leo.duran@amd.com>
Cc: edk2-devel@ml01.01.org
Subject: Re: [PATCH v3 0/4] Add PCD PcdPteMemoryEncryptionAddressOrMask
Date: Thu, 16 Feb 2017 22:56:00 +0100	[thread overview]
Message-ID: <ec83b052-1af7-c985-35a3-0838c5943add@redhat.com> (raw)
In-Reply-To: <1487278926-14303-1-git-send-email-leo.duran@amd.com>

On 02/16/17 22:02, Leo Duran wrote:
> This new PCD holds the address mask for page table entries when memory
> encryption is enabled on AMD processors supporting the Secure Encrypted
> Virtualization (SEV) feature.
> 
> This mask is be applied when creating 1:1 virtual to physical mapping tables.
> For example, the OvmfPkg sets the PCD when launching SEV-enabled guests.
> 
> Changes since v2:
> - Apply mask to PCD to keep value within Address field
> - Use variable instead of PCD in Page-Fault Handler
> 
> To-Do:
> - Add PCD support for page tables in UefiCpuPg/PiSmmCpuDxeSmm

>From a very superficial skim -- none of the patches are for OvmfPkg
after all! :) --, this approach looks good to me.

If I recall correctly, we're going to set the PCD in OVMF dynamically.
Is that right?

That usually requires investigating the possible orderings between "PCD
producer" and "PCD consumers". For DXE_DRIVER and DXE_SMM_DRIVER
consumers, it is good enough to set the PCD in OvmfPkg/PlatformPei
(which is a PEIM, so it's bound to run earlier -- PEI comes before DXE).

For PEIM consumers though, more thought might be necessary. OvmfPkg does
not pull in CapsulePei, so no need to worry about that.

Wrt. S3Resume2Pei: the dispatch order of S3Resume2Pei vs. PlatformPei is
unspecified (both have plain TRUE depexes). However, S3Resume2Pei does
not consume the PCD in its entry point function, only on the following
call path:

DxeLoadCore() [MdeModulePkg/Core/DxeIplPeim/DxeLoad.c]
  S3RestoreConfig2() [UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c]
    RestoreS3PageTables()
      PcdGet64(...)

IOW, the PCD is not consumed when S3Resume2Pei starts, but when the DXE
Initial Program Load PEIM realizes, at the end of the PEI phase, that
we're resuming, so it branches to EFI_PEI_S3_RESUME2_PPI, rather than
loading the DXE core (and starting the DXE phase).

So, I think setting the PCD in OvmfPkg/PlatformPei will be safe.

(BTW, if we had no such ordering guarantees between PlatformPei and
another PEIM, we could still make it work: we could hook a NULL class
library instance into all such PEIMs, and the lib constructor function
would (re-)set the PCD afresh in each, from whatever hw characteristics
SEV is detectable. Edk2 is awesome like that.

For an instance of this pattern (albeit in the DXE phase), please search
the OVMF DSC files for
"OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf".)

... Perhaps this has been obvious, but I thought it wouldn't be useless
to mention.

Thanks
Laszlo

> Leo Duran (4):
>   MdeModulePkg: Add PCD PcdPteMemoryEncryptionAddressOrMask
>   MdeModulePkg/Universal/CapsulePei:     Add support for PCD
>     PcdPteMemoryEncryptionAddressOrMask
>   UefiCpuPkg/Universal/Acpi/S3Resume2Pei:     Add support for PCD
>     PcdPteMemoryEncryptionAddressOrMask
>   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe:     Add support for
>     PCD PcdPteMemoryEncryptionAddressOrMask
> 
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf            |  5 +++-
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   | 29 ++++++++++++++++------
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h   |  6 +++++
>  MdeModulePkg/MdeModulePkg.dec                      |  8 ++++++
>  .../BootScriptExecutorDxe.inf                      |  2 ++
>  .../Acpi/BootScriptExecutorDxe/ScriptExecute.c     |  7 ++++++
>  .../Acpi/BootScriptExecutorDxe/ScriptExecute.h     |  2 ++
>  .../Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c   | 16 ++++++++----
>  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf   |  2 ++
>  .../Universal/CapsulePei/Common/CommonHeader.h     |  7 ++++++
>  MdeModulePkg/Universal/CapsulePei/UefiCapsule.c    | 13 +++++++---
>  MdeModulePkg/Universal/CapsulePei/X64/X64Entry.c   | 23 +++++++++++------
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 16 +++++++++---
>  .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |  2 ++
>  14 files changed, 109 insertions(+), 29 deletions(-)
> 



      parent reply	other threads:[~2017-02-16 21:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 21:02 [PATCH v3 0/4] Add PCD PcdPteMemoryEncryptionAddressOrMask Leo Duran
2017-02-16 21:02 ` [PATCH v3 1/4] MdeModulePkg: " Leo Duran
2017-02-16 21:02 ` [PATCH v3 2/4] MdeModulePkg/Universal/CapsulePei: Add support for " Leo Duran
2017-02-20  6:04   ` Zeng, Star
2017-02-21 16:42     ` Duran, Leo
2017-02-22  1:20       ` Zeng, Star
2017-02-22 15:07         ` Duran, Leo
2017-02-16 21:02 ` [PATCH v3 3/4] UefiCpuPkg/Universal/Acpi/S3Resume2Pei: " Leo Duran
2017-02-16 21:02 ` [PATCH v3 4/4] MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe: " Leo Duran
2017-02-16 21:56 ` Laszlo Ersek [this message]

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=ec83b052-1af7-c985-35a3-0838c5943add@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