From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 23EC021A1349E for ; Mon, 15 May 2017 10:47:39 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2017 10:47:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,346,1491289200"; d="scan'208";a="261867361" Received: from casander-mobl.amr.corp.intel.com (HELO localhost) ([10.254.34.31]) by fmsmga004.fm.intel.com with ESMTP; 15 May 2017 10:47:38 -0700 MIME-Version: 1.0 To: Brijesh Singh , Laszlo Ersek , edk2-devel@lists.01.org Message-ID: <149487045771.31444.19976106484440238@jljusten-skl> From: Jordan Justen In-Reply-To: Cc: Thomas.Lendacky@amd.com, leo.duran@amd.com, Jiewen Yao References: <1494454162-9940-1-git-send-email-brijesh.singh@amd.com> <1494454162-9940-7-git-send-email-brijesh.singh@amd.com> <1ebdde6a-bad7-ed9a-b2af-7334477c8ae3@redhat.com> <149452462682.9607.8151737434916832513@jljusten-skl.jf.intel.com> User-Agent: alot/0.5.1 Date: Mon, 15 May 2017 10:47:37 -0700 Subject: Re: [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 17:47:39 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-05-11 11:01:57, Brijesh Singh wrote: > = > = > On 05/11/2017 12:43 PM, Jordan Justen wrote: > > On 2017-05-11 08:53:39, Laszlo Ersek wrote: > >> (5) Please mention that the driver is being added to the APRIORI DXE > >> file for a separate reason as well (not just for the early clearing of > >> the C bit on MMIO/NonExistent): OvmfPkg's DXE phase modules that tailor > >> their behavior to SEV presence will assume that the IOMMU protocol > >> exported by this driver is available *at once*. > > > > What other code depends on this being run apriori? > > > = > We basically need some kind of guarantee that this driver is run before a= ny other > drivers or libs access MMIO register/buffers. In additional to clearing e= ncryption > bit from MMIO spaces, the driver also installs IOMMU protocol. So far, IO= MMU 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. 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. -Jordan > To answer your question, any code which uses MMIO or DMA in Dxe phase dep= ends on this > driver run as APRIORI. > = > -Brijesh > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel