public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: Brijesh Singh <brijesh.singh@amd.com>,
	Laszlo Ersek <lersek@redhat.com>,
	edk2-devel@lists.01.org
Cc: Thomas.Lendacky@amd.com, leo.duran@amd.com,
	Jiewen Yao <jiewen.yao@intel.com>
Subject: Re: [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver
Date: Tue, 16 May 2017 10:56:37 -0700	[thread overview]
Message-ID: <149495739728.2794.9440373089056382638@jljusten-skl> (raw)
In-Reply-To: <89da82c5-1e23-190b-0725-76f4da595987@amd.com>

On 2017-05-16 05:04:58, Brijesh Singh wrote:
> Hi Jordan,
> 
> On 5/15/17 12:47 PM, Jordan Justen wrote:
> > On 2017-05-11 11:01:57, Brijesh Singh wrote:
> >>
> >> We basically need some kind of guarantee that this driver is run before any other
> >> drivers or libs access MMIO register/buffers. In additional to clearing encryption
> >> bit from MMIO spaces, the driver also installs IOMMU protocol. So far, IOMMU protocol
> >> is directly consumed by PciHostBridgeDxe driver and QemuFwCfgDxeLib.
> > What about adding a NULL protocol named
> > gOvmfIoMmuDetectionProtocolGuid? (Better name suggestions welcomed. :)
> > Then we can use this protocol in a depex where needed.
> It should be doable, If I find better name then I will use that :)
> > Maybe we should consider naming the driver IoMmuDxe instead?
> >
> > I think the generic PciRoot bridge driver shouldn't need this in the
> > depex because it will not start until the BDS phase, and the IoMmuDxe
> > driver would have been dispatched by then.
> Are you suggesting that we introduce a new IoMmuDxe driver and install
> IOMMU protocol unconditionally ?

No. I'm suggesting we have a new protocol that only exists to allow
dependency expressions to know that we've attempted to detect an IoMmu
implementation.

The driver would "install" the protocol with a NULL pointer regardless
of whether the IoMmu protocol was installed. Maybe
gOvmfIoMmuDetectionAttemptedProtocolGuid would be a better name?

The DXE fw-cfg library should then list this under depex. I think the
PCI Host bridge driver doesn't require the depex for the reason I
mentioned abobe.

The gEdkiiIoMmuProtocolGuid protocol would only be installed be
installed when detected like your patches currently do.

This method should allow the driver runtime order dependency to be
explicitly indicated.

Regarding the 'IoMmuDxe' name, I was suggesting that AmdSevDxe be
renamed to IoMmuDxe. Since we would be installing the 'we tried to
detect iommu' protocol, it probably makes sense to put all the iommu
implementation support into a single driver and only install the
'detection attempted' protocol it after trying to detect all supported
iommu implementations.

There could be an issue with this. FvbServicesRuntimeDxe.inf is in the
apriori currently if SMM_REQUIRE is set, so if it needs the iommu
treatment, then this wouldn't work. This driver does use MM I/O just
below 4GB. I don't think your current patches would change how this
driver runs since it doesn't use the PCI host bridge protocol, so I
guess it is ok?

(It would be nice to get FvbServicesRuntimeDxe.inf out of the apriori
too, but that is a separate issue.)

-Jordan

> I was hoping that we install IOMMU
> protocol only when SEV is enabled. A non-SEV guest will still use the
> old approach.  I was minimizing changes into non-SEV code flow.  Please
> note that since AmdSevDxe driver does *two* things; a) clear C-bit from
> MMIO b) installs IOMMU protocol hence I will not able to remove 
> AmdSevDxe completely.  But I can remove IOMMU protocol installation part
> from AmdSevDxe and move it into new IoMmuDxe driver.  Please let me know
> if this is what you are asking.  thanks
> 
> -Brijesh


  reply	other threads:[~2017-05-16 17:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-10 22:09 [RFC v4 00/13] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-05-10 22:09 ` [RFC v4 01/13] UefiCpuPkg: Define AMD Memory Encryption specific CPUID and MSR Brijesh Singh
2017-05-11  0:30   ` Fan, Jeff
2017-05-10 22:09 ` [RFC v4 02/13] OvmfPkg/ResetVector: Set C-bit when building initial page table Brijesh Singh
2017-05-11 11:40   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 03/13] OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf Brijesh Singh
2017-05-11 11:46   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 04/13] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library Brijesh Singh
2017-05-11 14:04   ` Laszlo Ersek
2017-05-11 18:03     ` Brijesh Singh
2017-05-10 22:09 ` [RFC v4 05/13] OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled Brijesh Singh
2017-05-11 14:37   ` Laszlo Ersek
2017-05-11 18:04     ` Brijesh Singh
2017-05-10 22:09 ` [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver Brijesh Singh
2017-05-11  0:56   ` Yao, Jiewen
2017-05-11 15:19   ` Laszlo Ersek
2017-05-11 15:53     ` Laszlo Ersek
2017-05-11 17:43       ` Jordan Justen
2017-05-11 18:01         ` Brijesh Singh
2017-05-15 17:47           ` Jordan Justen
2017-05-16 12:04             ` Brijesh Singh
2017-05-16 17:56               ` Jordan Justen [this message]
2017-05-16 20:25                 ` Brijesh Singh
2017-05-18  8:50                   ` Laszlo Ersek
2017-05-11 20:14         ` Laszlo Ersek
2017-05-11 18:12     ` Brijesh Singh
2017-05-10 22:09 ` [RFC v4 07/13] OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library Brijesh Singh
2017-05-11 15:40   ` Laszlo Ersek
2017-05-11 18:16     ` Brijesh Singh
2017-05-10 22:09 ` [RFC v4 08/13] OvmfPkg/QemuFwCfgLib: Prepare for SEV support Brijesh Singh
2017-05-11 15:57   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 09/13] OvmfPkg/QemuFwCfgLib: Implement SEV internal function for SEC phase Brijesh Singh
2017-05-11 16:24   ` Laszlo Ersek
2017-05-11 18:21     ` Brijesh Singh
2017-05-10 22:09 ` [RFC v4 10/13] OvmfPkg/QemuFwCfgLib: Implement SEV internal functions for PEI phase Brijesh Singh
2017-05-11 16:38   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 11/13] OvmfPkg/QemuFwCfgLib: Implement SEV internal function for Dxe phase Brijesh Singh
2017-05-11 17:07   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 12/13] OvmfPkg/QemuFwCfgLib: Add option to dynamic alloc FW_CFG_DMA Access Brijesh Singh
2017-05-11 17:10   ` Laszlo Ersek
2017-05-10 22:09 ` [RFC v4 13/13] OvmfPkg/QemuFwCfgLib: Add SEV support Brijesh Singh
2017-05-11 17:44   ` Laszlo Ersek

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=149495739728.2794.9440373089056382638@jljusten-skl \
    --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