From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
Brijesh Singh <brijesh.singh@amd.com>,
edk2-devel@lists.01.org
Cc: Thomas.Lendacky@amd.com, leo.duran@amd.com,
Jeff Fan <jeff.fan@intel.com>, Liming Gao <liming.gao@intel.com>,
Jiewen Yao <jiewen.yao@intel.com>
Subject: Re: [PATCH v6 00/17] x86: Secure Encrypted Virtualization (AMD)
Date: Mon, 29 May 2017 13:16:15 +0200 [thread overview]
Message-ID: <6ecd0138-454e-6a6e-d034-beaf63466120@redhat.com> (raw)
In-Reply-To: <149583274037.25973.13062338567511386932@jljusten-skl>
(looks like I was the one to comment as second reviewer after all :) )
On 05/26/17 23:05, Jordan Justen wrote:
> On 2017-05-26 07:43:48, Brijesh Singh wrote:
>> Changes since v4:
>> - decouple IoMmu protocol implementation from AmdSevDxe into a seperate
>> IoMmuDxe driver. And introduce a placeholder protocol to provide the
>> dependency support for the dependent modules.
>
> I think you split IoMmuDxe out from AmdSevDxe based on my feedback
> regarding APRIORI, but I don't think this helped.
>
> Ideally I would like to see one driver named IoMmuDxe that is *not* in
> APRIORI.
There are two separate goals here:
(1) Make sure that any driver that adds MMIO ranges will automatically
add those ranges with the C bit cleared in the PTEs, without actually
knowing about SEV.
(2) Provide an IOMMU protocol for those drivers that explicitly map /
unmap memory for DMA(-like) transfers.
Goal (2) is covered by the IOMMU protocol, and dependent drivers in
category (2) can be nicely ordered against IoMmuDxe with the OR depex (=
depend on the IOMMU protocol or the placeholder).
Goal (1) is a separate question. For covering goal (1), there are two
options:
(1a) modify all MMIO-adding drivers individually, to clear the C-bit.
(1b) do something general that will affect all MMIO additions at once,
without modifying individual drivers.
(1a) is ugly and it doesn't scale.
For (1b), there are again two possibilities:
(1b1) modify the GCD memory space map gDS services, so they handle SEV
internally,
(1b2) right after we enter the DXE phase (before any MMIO-adding driver
gets a chance to be dispatched), clear the C bit for all NonExistent
ranges (where MMIO might be added later) and for all currently existing
MMIO ranges (which come from the DXE core initialization, according to
MMIO memory descriptor HOBs from PEI).
I don't think we can express "right after we enter the DXE phase"
without an APRIORI entry; DEPEXes don't seem realistic for this.
Option (1b1) could still work, but as far as I remember (I could be
wrong!), Jiewen didn't like that, and he suggested (1b2) as the alternative.
> I think because of QemuFlashFvbServicesRuntimeDxe in APRIORI, we also
> need IoMmuDxe in the APRIORI.
QemuFlashFvbServicesRuntimeDxe adds the flash range as runtime,
uncacheable, system memory to the GCD memory space map (and then
allocates it at once). In practice it is used like MMIO, and therefore
the driver falls under category (1). Consequently, it should be
addressed with:
- either (1a) -- clear the C bit manually,
- or (1b1) -- modify the gDS services --> automatic C-bit clearing,
- or (1b2) -- assign the area with the C-bit pre-cleared.
- (or even (2) -- rework the driver to consume the IOMMU protocol
explicitly.)
Are you suggesting the last option -- rework
QemuFlashFvbServicesRuntimeDxe so that it consumes the IOMMU protocol?
In my opinion, that option is conceptually not much different from (1a)
-- which I don't like --, because it again implements a case-by-case
modification of an MMIO driver. Instead, I prefer SEV to be transparent
to drivers that don't already do *explicit* DMA.
> Hopefully we can figure our how to
> remove QemuFlashFvbServicesRuntimeDxe and then be able to remove
> IoMmuDxe.
The reason why QemuFlashFvbServicesRuntimeDxe is in APRIORI, and the
reason why AmdSevDxe is in APRIORI, are different.
* QemuFlashFvbServicesRuntimeDxe is in APRIORI -- and that's only when
SMM_REQUIRE is FALSE -- because it competes with
EmuVariableFvbRuntimeDxe, and QemuFlashFvbServicesRuntimeDxe takes
priority. EmuVariableFvbRuntimeDxe is only part of the build when
SMM_REQUIRE is false. When SMM_REQUIRE is TRUE, there is no competition,
and QemuFlashFvbServicesRuntimeDxe is not in APRIORI.
* AmdSevDxe is part of APRIORI because it must pre-clear the C bit for
*all* MMIO(-like) drivers.
If you move QemuFlashFvbServicesRuntimeDxe out of APRIORI (for example,
either by defining SMM_REQUIRE, or by inventing a different
serialization vehicle against EmuVariableFvbRuntimeDxe), AmdSevDxe
*still* has to remain in APRIORI, because it still must clear the C bit
for *all* MMIO(-like) drivers.
In my opinion, the current version of the patch set (v6) accurately
reflects option (1b2). And option (1b2) requires APRIORI usage.
If you dislike that, I think we'll have to go back to another option:
(1a), which I dislike; (1b1), which Jiewen dislikes (IIRC); or (2),
which I again dislike for all MMIO drivers that don't already use
explicit DMA.
Thanks
Laszlo
>> - update debug messages to use gEfiCallerBaseName where applicable.
>> - fix QemuFwCfgSecLib build errors and simplify SEV support
>> - update QemuFwCfgDxeLib to assert when failed to locate IOMMU
>> - update comments "host buffer" to " host buffer"
>>
>> Changes since v3:
>> - update AmdSevDxe driver to produce IOMMU protocol
>> - remove BmDmaLib dependency
>> - update QemuFwCfgLib to use IOMMU protocol to allocate SEV DMA buffer
>>
>> Changes since v2:
>> - move memory encryption CPUID and MSR definition into UefiCpuPkg
>> - fix the argument order for SUB instruction in ResetVector and add more
>> comments
>> - update PlatformPei to use BaseMemEncryptSevLib
>> - break the overlong comment lines to 79 chars
>> - variable aligment and other formating fixes
>> - split the SEV DMA support patch for QemuFwCfgLib into multiple patches as
>> recommended by Laszlo
>> - add AmdSevDxe driver which runs very early in DXE phase and clear the C-bit
>> from MMIO memory region
>> - drop 'QemuVideoDxe: Clear C-bit from framebuffer' patch since AmdSevDxe
>> driver takes care of clearing the C-bit from MMIO region
>> - Verified that Qemu PFLASH works fine with SEV guest, Found a KVM driver issue
>> which was causing #PF when PFLASH was enabled. I have submitted patch to
>> fix it in upstream http://marc.info/?l=kvm&m=149304930814202&w=2
>>
>> Changes since v1:
>> - bug fixes in OvmfPkg/ResetVector (pointed by Tom Lendacky)
>> - add SEV CPUID and MSR register definition in standard include file
>> - remove the MemEncryptLib dependency from PlatformPei. Move AmdSevInitialize()
>> implementation in local file inside the PlatformPei package
>> - rename MemCryptSevLib to MemEncryptSevLib and add functions to set or
>> clear memory encryption attribute on memory region
>> - integerate SEV support in BmDmaLib
>> - split QemuFwCfgDxePei.c into QemuFwCfgDxe.c and QemuFwCfgPei.c to
>> allow building seperate QemuFwCfgLib for Dxe and Pei phase
>> (recommended by Laszlo Ersek)
>> - add SEV support in QemuFwCfgLib
>> - clear the memory encryption attribute from framebuffer memory region
>>
>>
>> TODO:
>> (Will add these features after basic SEV support patches are accepted in upstream)
>> - add support for DMA operation in QemuFwCfgS3Lib when SEV is enabled
>> - investigate SMM/SMI support
>>
>> Cc: Jeff Fan <jeff.fan@intel.com>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Leo Duran <leo.duran@amd.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Leo Duran <leo.duran@amd.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>> Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>>
>> Brijesh Singh (17):
>> UefiCpuPkg: Define AMD Memory Encryption specific CPUID and MSR
>> OvmfPkg/ResetVector: Set C-bit when building initial page table
>> OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf
>> OvmfPkg/BaseMemcryptSevLib: Add SEV helper library
>> OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled
>> OvmfPkg: Add AmdSevDxe driver
>> OvmfPkg: Introduce IoMmuAbsent Protocol GUID
>> OvmfPkg: Add PlatformHasIoMmuLib
>> OvmfPkg: Add IoMmuDxe driver
>> OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library
>> OvmfPkg/QemuFwCfgLib: Prepare for SEV support
>> OvmfPkg/QemuFwCfgLib: Implement SEV internal function for SEC phase
>> OvmfPkg/QemuFwCfgLib: Implement SEV internal functions for PEI phase
>> OvmfPkg/QemuFwCfgLib: Implement SEV internal function for Dxe phase
>> OvmfPkg/QemuFwCfgLib: Add option to dynamic alloc FW_CFG_DMA Access
>> OvmfPkg/QemuFwCfgLib: Add SEV support
>> OvmfPkg: update PciHostBridgeDxe to use PlatformHasIoMmuLib
>>
>> OvmfPkg/OvmfPkg.dec | 1 +
>> OvmfPkg/OvmfPkgIa32.dsc | 11 +-
>> OvmfPkg/OvmfPkgIa32X64.dsc | 12 +-
>> OvmfPkg/OvmfPkgX64.dsc | 12 +-
>> OvmfPkg/OvmfPkgIa32.fdf | 1 +
>> OvmfPkg/OvmfPkgIa32X64.fdf | 3 +
>> OvmfPkg/OvmfPkgX64.fdf | 3 +
>> OvmfPkg/AmdSevDxe/AmdSevDxe.inf | 43 ++
>> OvmfPkg/IoMmuDxe/IoMmuDxe.inf | 49 +++
>> OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf | 50 +++
>> OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf | 37 ++
>> OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgLib.inf => QemuFwCfgDxeLib.inf} | 15 +-
>> OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgLib.inf => QemuFwCfgPeiLib.inf} | 9 +-
>> OvmfPkg/PlatformPei/PlatformPei.inf | 3 +
>> OvmfPkg/Include/Library/MemEncryptSevLib.h | 81 ++++
>> OvmfPkg/IoMmuDxe/AmdSevIoMmu.h | 43 ++
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h | 184 ++++++++
>> OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibInternal.h | 37 ++
>> OvmfPkg/PlatformPei/Platform.h | 5 +
>> UefiCpuPkg/Include/Register/Amd/Cpuid.h | 162 +++++++
>> UefiCpuPkg/Include/Register/Amd/Fam17Msr.h | 62 +++
>> UefiCpuPkg/Include/Register/Amd/Msr.h | 29 ++
>> OvmfPkg/AmdSevDxe/AmdSevDxe.c | 75 ++++
>> OvmfPkg/IoMmuDxe/AmdSevIoMmu.c | 459 ++++++++++++++++++++
>> OvmfPkg/IoMmuDxe/IoMmuDxe.c | 53 +++
>> OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c | 84 ++++
>> OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c | 90 ++++
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/MemEncryptSevLib.c | 84 ++++
>> OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c | 439 +++++++++++++++++++
>> OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.c | 32 ++
>> OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c | 230 ++++++++++
>> OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 67 ++-
>> OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgPeiDxe.c => QemuFwCfgPei.c} | 72 ++-
>> OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSec.c | 57 +++
>> OvmfPkg/PlatformPei/AmdSev.c | 62 +++
>> OvmfPkg/PlatformPei/Platform.c | 1 +
>> OvmfPkg/ResetVector/Ia32/PageTables64.asm | 70 ++-
>> 37 files changed, 2703 insertions(+), 24 deletions(-)
>> create mode 100644 OvmfPkg/AmdSevDxe/AmdSevDxe.inf
>> create mode 100644 OvmfPkg/IoMmuDxe/IoMmuDxe.inf
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
>> create mode 100644 OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
>> copy OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgLib.inf => QemuFwCfgDxeLib.inf} (71%)
>> rename OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgLib.inf => QemuFwCfgPeiLib.inf} (80%)
>> create mode 100644 OvmfPkg/Include/Library/MemEncryptSevLib.h
>> create mode 100644 OvmfPkg/IoMmuDxe/AmdSevIoMmu.h
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.h
>> create mode 100644 UefiCpuPkg/Include/Register/Amd/Cpuid.h
>> create mode 100644 UefiCpuPkg/Include/Register/Amd/Fam17Msr.h
>> create mode 100644 UefiCpuPkg/Include/Register/Amd/Msr.h
>> create mode 100644 OvmfPkg/AmdSevDxe/AmdSevDxe.c
>> create mode 100644 OvmfPkg/IoMmuDxe/AmdSevIoMmu.c
>> create mode 100644 OvmfPkg/IoMmuDxe/IoMmuDxe.c
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/Ia32/MemEncryptSevLib.c
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/MemEncryptSevLibInternal.c
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/X64/MemEncryptSevLib.c
>> create mode 100644 OvmfPkg/Library/BaseMemEncryptSevLib/X64/VirtualMemory.c
>> create mode 100644 OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.c
>> create mode 100644 OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxe.c
>> rename OvmfPkg/Library/QemuFwCfgLib/{QemuFwCfgPeiDxe.c => QemuFwCfgPei.c} (61%)
>> create mode 100644 OvmfPkg/PlatformPei/AmdSev.c
>>
>> --
>> 2.7.4
>>
next prev parent reply other threads:[~2017-05-29 11:15 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 14:43 [PATCH v6 00/17] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 01/17] UefiCpuPkg: Define AMD Memory Encryption specific CPUID and MSR Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 02/17] OvmfPkg/ResetVector: Set C-bit when building initial page table Brijesh Singh
2017-06-01 8:09 ` Jordan Justen
2017-06-01 13:43 ` Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 03/17] OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 04/17] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library Brijesh Singh
2017-05-26 20:54 ` Jordan Justen
2017-05-26 21:06 ` Brijesh Singh
2017-05-27 1:26 ` Yao, Jiewen
2017-05-26 14:43 ` [PATCH v6 05/17] OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 06/17] OvmfPkg: Add AmdSevDxe driver Brijesh Singh
2017-05-26 14:43 ` [PATCH v6 07/17] OvmfPkg: Introduce IoMmuAbsent Protocol GUID Brijesh Singh
2017-05-29 9:07 ` Laszlo Ersek
2017-05-26 14:43 ` [PATCH v6 08/17] OvmfPkg: Add PlatformHasIoMmuLib Brijesh Singh
2017-05-29 9:19 ` Laszlo Ersek
2017-05-26 14:43 ` [PATCH v6 09/17] OvmfPkg: Add IoMmuDxe driver Brijesh Singh
2017-05-29 9:28 ` Laszlo Ersek
2017-05-26 14:43 ` [PATCH v6 10/17] OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library Brijesh Singh
2017-05-26 21:49 ` Jordan Justen
2017-05-26 14:43 ` [PATCH v6 11/17] OvmfPkg/QemuFwCfgLib: Prepare for SEV support Brijesh Singh
2017-05-26 14:44 ` [PATCH v6 12/17] OvmfPkg/QemuFwCfgLib: Implement SEV internal function for SEC phase Brijesh Singh
2017-05-26 14:44 ` [PATCH v6 13/17] OvmfPkg/QemuFwCfgLib: Implement SEV internal functions for PEI phase Brijesh Singh
2017-05-26 14:44 ` [PATCH v6 14/17] OvmfPkg/QemuFwCfgLib: Implement SEV internal function for Dxe phase Brijesh Singh
2017-05-29 9:40 ` Laszlo Ersek
2017-05-26 14:44 ` [PATCH v6 15/17] OvmfPkg/QemuFwCfgLib: Add option to dynamic alloc FW_CFG_DMA Access Brijesh Singh
2017-05-26 14:44 ` [PATCH v6 16/17] OvmfPkg/QemuFwCfgLib: Add SEV support Brijesh Singh
2017-05-26 14:44 ` [PATCH v6 17/17] OvmfPkg: update PciHostBridgeDxe to use PlatformHasIoMmuLib Brijesh Singh
2017-05-29 9:47 ` Laszlo Ersek
2017-05-29 12:13 ` Laszlo Ersek
2017-05-26 21:05 ` [PATCH v6 00/17] x86: Secure Encrypted Virtualization (AMD) Jordan Justen
2017-05-29 11:16 ` Laszlo Ersek [this message]
2017-05-29 20:38 ` Jordan Justen
2017-05-29 21:59 ` Brijesh Singh
2017-06-01 7:40 ` Jordan Justen
2017-06-01 9:10 ` Laszlo Ersek
2017-06-01 13:48 ` Andrew Fish
2017-06-01 14:56 ` Laszlo Ersek
2017-06-01 15:01 ` Brijesh Singh
2017-06-01 15:37 ` Andrew Fish
2017-06-05 21:56 ` Brijesh Singh
2017-06-06 1:12 ` Jordan Justen
2017-06-06 2:08 ` Zeng, Star
2017-06-06 3:50 ` Brijesh Singh
2017-06-06 14:54 ` Yao, Jiewen
2017-06-06 15:24 ` Andrew Fish
2017-06-06 15:43 ` Yao, Jiewen
2017-06-06 15:54 ` Duran, Leo
2017-06-06 18:39 ` Laszlo Ersek
2017-06-06 18:38 ` Laszlo Ersek
2017-06-06 18:29 ` Laszlo Ersek
2017-06-06 18:57 ` Duran, Leo
2017-07-05 22:31 ` Brijesh Singh
2017-07-05 23:38 ` Laszlo Ersek
2017-07-06 13:37 ` Brijesh Singh
2017-07-06 16:45 ` Jordan Justen
2017-07-06 20:11 ` Brijesh Singh
2017-07-06 20:40 ` Laszlo Ersek
2017-07-06 21:42 ` Jordan Justen
2017-07-06 21:44 ` Duran, Leo
2017-07-06 21:46 ` Andrew Fish
2017-07-06 21:49 ` Duran, Leo
2017-07-07 5:28 ` Jordan Justen
2017-07-07 18:29 ` Brijesh Singh
2017-07-07 23:10 ` Jordan Justen
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=6ecd0138-454e-6a6e-d034-beaf63466120@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