Re: [PATCH] MdePkg: Add DmaRemappingReportingTable.h

["Kinney, Michael D" <michael.d.kinney@intel.com>]

Giri,

Based on the information in this thread, I am in favor of adding to MdePkg.

If the number of files in MdePkg/Include/IndustryStandard grows too large
then some additional directory organization may be required.

Mike

> -----Original Message-----
> From: Mudusuru, Giri P
> Sent: Monday, August 1, 2016 9:52 AM
> To: Rothman, Michael A <michael.a.rothman@intel.com>; Tim Lewis <tim.lewis@insyde.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> devel@lists.01.org <edk2-devel@ml01.01.org>
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>; Mudusuru,
> Giri P <giri.p.mudusuru@intel.com>
> Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> 
> Thanks for detailed conversation and I agree with direction.
> 
> As it is ACPI related which has multiple vendors owning specific tables referred by
> ACPI spec MdePkg for now seems to be right place. That said we can start separate
> discussion if we want to create vendor folders for better organization in future.
> 
> For now we can close this thread to include in MdePkg. Any objections?
> 
> Thanks,
> -Giri
> 
> > -----Original Message-----
> > From: Rothman, Michael A
> > Sent: Thursday, July 28, 2016 11:53 AM
> > To: Mudusuru, Giri P <giri.p.mudusuru@intel.com>; Tim Lewis
> > <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> > Laszlo Ersek <lersek@redhat.com>; edk2-devel@lists.01.org <edk2-
> > devel@ml01.01.org>
> > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
> > Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> >
> > Personally,
> >
> > I see that we have two classes of data we have external references to in the
> > codebase.
> >
> > We have data that is in a standards-maintained spec like ACPI, UEFI, etc.  This
> > might be something like FPDT, which is a reservation in ACPI, but also has a
> > litany of definitions contained within the main ACPI specification and bug fixes
> > or extensions associated with it will show up in the main spec.
> >
> > We also have data that one of the main industry specs may reference, but don't
> > define explicitly. Things like the PE/COFF format, XENV, DMAR, etc. These are
> > maintained by vendor owners such as MSFT, INTC, or others.
> >
> > In my mind, both of these categories are in essence industry spec material.
> > They're used by the industry and thus at least show up in some form within the
> > main industry specs.
> >
> > However, the key difference is who is maintaining it.
> >
> > I can easily see argued that the industrystandard directory should contain them
> > all.
> > I could further argue that if we end up having too much in the main
> > industrystandard directory, we could start to bucket them by having
> > subdirectories noting who maintains it.
> >
> > Being that it is reference by an industry standard seems to be the simplest litmus
> > test for what main directory (and thus .h file) it gets placed in - otherwise it
> > might get pretty confusing.
> >
> > Definitely feels like something the Codebase Grand Poobahs(Kinney/Fish/Leif)
> > need to discuss. :-)
> >
> > Thanks,
> > Mike Rothman
> > (迈克 罗斯曼 / माइकल रोथ्मेन् / Михаил Ротман / משה רוטמן)
> > רועה עיקרי של חתולים
> >
> >
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Mudusuru, Giri P
> > Sent: Thursday, July 28, 2016 10:59 AM
> > To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D
> > <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> > devel@lists.01.org <edk2-devel@ml01.01.org>
> > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
> > Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> >
> > Hi Tim,
> > Yes it is historical, and if we want to change that let's define the guidelines.
> >
> > In initial review added to IntelSiliconPkg but looking at other usage and to keep
> > it consistent I have moved to MdePkg.
> >
> > For example HPET and SPMI is another example which falls under the same
> > bucket from Intel side.
> >
> > For now we have place for Intel silicon related at IntelSiliconPkg but not all
> > vendors have same.
> >
> > Will wait for the stewards (Mike, Leif and Andrew) to recommend the final
> > location.
> >
> > Thanks,
> > -Giri
> >
> > > -----Original Message-----
> > > From: Tim Lewis [mailto:tim.lewis@insyde.com]
> > > Sent: Thursday, July 28, 2016 9:55 AM
> > > To: Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek
> > > <lersek@redhat.com>; Mudusuru, Giri P <giri.p.mudusuru@intel.com>;
> > > edk2- devel@lists.01.org <edk2-devel@ml01.01.org>
> > > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming
> > > <liming.gao@intel.com>
> > > Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> > >
> > > Mike --
> > >
> > > Not quite. That table has historically been a registry of claimed
> > > table IDs similar to the registry for \EFI directory names. As noted,
> > > there is a link to a page that gives the links to the actual spec,
> > > which is hosted by Intel (or Microsoft or Xen) The listing in this
> > > table is not an endorsement of an "industry standard" any more than XENV.
> > (XEN Project Table). They are just vendor links.
> > >
> > > Tim
> > >
> > > -----Original Message-----
> > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
> > > Sent: Thursday, July 28, 2016 9:51 AM
> > > To: Tim Lewis <tim.lewis@insyde.com>; Laszlo Ersek
> > > <lersek@redhat.com>; Mudusuru, Giri P <giri.p.mudusuru@intel.com>;
> > > edk2-devel@lists.01.org <edk2- devel@ml01.01.org>; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: Yao, Jiewen <jiewen.yao@intel.com>; Gao, Liming
> > > <liming.gao@intel.com>
> > > Subject: RE: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> > >
> > > Tim,
> > >
> > > The 'DMAR' table is defined in the ACPI Specification.
> > >
> > > This is similar to 'DBG2':
> > >
> > >   MdePkg/Include/IndustryStandard/DebugPort2Table.h
> > >
> > > And 'SPCD':
> > >
> > >   MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > >
> > > Mike
> > >
> > > > -----Original Message-----
> > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
> > > > Of Tim Lewis
> > > > Sent: Thursday, July 28, 2016 9:42 AM
> > > > To: Laszlo Ersek <lersek@redhat.com>; Mudusuru, Giri P
> > > > <giri.p.mudusuru@intel.com>; edk2-devel@lists.01.org
> > > > <edk2-devel@ml01.01.org>
> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen
> > > > <jiewen.yao@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> > > >
> > > > Laszlo --
> > > >
> > > > I hear what you are saying. However, I think this is a different case:
> > > >
> > > > 1) How many ARM-defined standards are in the
> > > MdePkg\Include\IndustryStandards.h file?
> > > > By my count, none. This is by design. They are all in other packages.
> > > > DMAR is there because it was grandfathered in from a generation of
> > > > tianocore when only architectures provided by Intel were prevalent for UEFI.
> > > >  2) Now that there is an Intel package for Intel-silicon related
> > > > header files and modules, now is the time to move it.
> > > > 3) OS cases are a little different, since we don't usually produce
> > > > Microsoft (or Redhat or Canonical or BSD) specific modules for UEFI.
> > > > There are header files and a smattering of files that deal with these.
> > > > If we created a MicrosoftOsPkg, I'd move the header files there as well.
> > > >
> > > > Tim
> > > >
> > > > -----Original Message-----
> > > > From: Laszlo Ersek [mailto:lersek@redhat.com]
> > > > Sent: Thursday, July 28, 2016 9:29 AM
> > > > To: Tim Lewis <tim.lewis@insyde.com>; Giri P Mudusuru
> > > > <giri.p.mudusuru@intel.com>; edk2-devel@lists.01.org
> > > > <edk2-devel@ml01.01.org>
> > > > Cc: Michael Kinney <michael.d.kinney@intel.com>; Jiewen Yao
> > > > <jiewen.yao@intel.com>; Liming Gao <liming.gao@intel.com>
> > > > Subject: Re: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> > > >
> > > > On 07/28/16 18:00, Tim Lewis wrote:
> > > > > Giri --
> > > > >
> > > > > Is MdePkg the right place for this? This appears to be an
> > > > > Intel-specific definition, right? I understand that it was in
> > > > > IndustryStandard for EdkCompatibilityPkg, but it might do better
> > > > > now in the IntelSiliconPkg.
> > > >
> > > > DMAR is defined by a widely used industry standard / spec; I think
> > > > it belongs to MdePkg.
> > > >
> > > > Prior art (gathered with
> > > >
> > > >   git log --reverse --stat=1000 --stat-graph-width=20 --
> > > > MdePkg/Include/IndustryStandard
> > > >
> > > > and by searching for "Microsoft", case-insensitively):
> > > >
> > > > (1)
> > > >
> > > > commit 32df01ff685b9de50555bac040166b17a061ea9b
> > > > Author: Chao Zhang <chao.b.zhang@intel.com>
> > > > Date:   Wed May 13 08:27:04 2015 +0000
> > > >
> > > >     MdePkg: Add Microsoft UX capsule GUID & layout
> > > >
> > > >     Add Microsoft UX capsule GUID & layout into IndustryStandard
> > > >
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
> > > >     Reviewed-by: Gao Liming <liming.gao@intel.com>
> > > >
> > > >     git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17424
> > > > 6f19259b-4bc3-
> > > > 4df7-8a09-765794883524
> > > >
> > > >  MdePkg/Include/IndustryStandard/WindowsUxCapsule.h | 46
> > > > ++++++++++++++++++++
> > > >  1 file changed, 46 insertions(+)
> > > >
> > > > (2)
> > > >
> > > > commit c374aa43a199a5aab53218ef3cf99284ba19ae98
> > > > Author: Heyi Guo <heyi.guo@linaro.org>
> > > > Date:   Fri Nov 13 03:27:54 2015 +0000
> > > >
> > > >     Update SPCR table definition per SPCR specification v1.03.
> > > >
> > > >     Document link:
> > > >
> > > > http://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=
> > > > vs
> > > > .85).aspx
> > > >
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: "Heyi Guo" <heyi.guo@linaro.org>
> > > >     Reviewed-by: "Jiewen Yao" <jiewen.yao@intel.com>
> > > >
> > > >     git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18782
> > > > 6f19259b-4bc3-
> > > > 4df7-8a09-765794883524
> > > >
> > > >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > > |
> > > > 12 ++++++++----
> > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > (3)
> > > >
> > > > commit 31a9d3b419accbbc5463c71221b3b30a46f9ee73
> > > > Author: Yao, Jiewen <jiewen.yao@intel.com>
> > > > Date:   Tue Jan 19 13:17:10 2016 +0000
> > > >
> > > >     MdePkg: Update MorLock comment to latest doc.
> > > >
> > > >     Microsoft updated secure MOR lock document with version 2.
> > > >     So we update comment here.
> > > >
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
> > > >     Reviewed: "Zhang, Chao B" <chao.b.zhang@intel.com>
> > > >
> > > >
> > > >     git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19687
> > > > 6f19259b-4bc3-
> > > > 4df7-8a09-765794883524
> > > >
> > > >  MdePkg/Include/IndustryStandard/MemoryOverwriteRequestControlLock.h
> > > > |
> > > > 16 ++++++++-----
> > > > ---
> > > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > (4)
> > > >
> > > > commit a0606fc705f5bdfbe2366a7f3c6dd7491da74394
> > > > Author: Sami Mujawar <sami.mujawar@arm.com>
> > > > Date:   Fri Mar 4 14:58:33 2016 +0000
> > > >
> > > >     MdePkg: Add ARM Serial Port Subtype definitions
> > > >
> > > >     The Serial Port Console Redirection Table specification Version 1.03 -
> > > >     August 10, 2015 adds support for Serial Port Subtypes for ARM. These
> > > >     Subtypes are described in the Table 3 of the Microsoft Debug Port Table
> > > >     2 (DBG2) Specification - December 10, 2015.
> > > >
> > > >     This patch adds macro definitions for these.
> > > >
> > > >     Code at:
> > > >
> > >
> > https://github.com/EvanLloyd/tianocore/commit/79678a0f399e97883cfba092
> > > > 75e750861e24cd70
> > > >
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
> > > >     Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
> > > >     Reviewed-by: Liming Gao <liming.gao@intel.com>
> > > >
> > > >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > > |
> > > > 25
> > > > ++++++++++++++++++--
> > > >  1 file changed, 23 insertions(+), 2 deletions(-)
> > > >
> > > > (5)
> > > >
> > > > commit 9f0b995e64b8d6beec2edef7fdddc3374e624e42
> > > > Author: Sami Mujawar <sami.mujawar@arm.com>
> > > > Date:   Fri Mar 4 17:24:41 2016 +0000
> > > >
> > > >     MdePkg: Add ARM Serial Port Subtypes to DBG2
> > > >
> > > >     The Microsoft Debug Port Table 2 (DBG2) specification revision
> > > >     October 6, 2015 adds support for Serial Port Subtypes for ARM.
> > > >
> > > >     This patch adds these definitions.
> > > >
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
> > > >     Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
> > > >     Reviewed-by: Liming Gao <liming.gao@intel.com>
> > > >
> > > >  MdePkg/Include/IndustryStandard/DebugPort2Table.h | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > >
> > > > (6)
> > > >
> > > > commit 6a0d24221241bb1b13bafc7b2d264240d19d2993
> > > > Author: Jiewen Yao <jiewen.yao@intel.com>
> > > > Date:   Fri Apr 22 10:23:19 2016 +0800
> > > >
> > > >     MdePkg: Add WSMT definition.
> > > >
> > > >     This patch adds Windows SMM Security Mitigation
> > > >     Table @
> > > > http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-
> > > BAA2-
> > > > 1A54E0E490B6/WSMT.docx
> > > >
> > > >     Cc: "Gao, Liming" <liming.gao@intel.com>
> > > >     Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>
> > > >     Contributed-under: TianoCore Contribution Agreement 1.0
> > > >     Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
> > > >     Reviewed-by: "Gao, Liming" <liming.gao@intel.com>
> > > >
> > > >  MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h
> > > > |
> > > > 39
> > > > ++++++++++++++++++++
> > > >  1 file changed, 39 insertions(+)
> > > >
> > > > Thanks
> > > > Laszlo
> > > >
> > > > > -----Original Message-----
> > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
> > > > > Behalf Of Giri P Mudusuru
> > > > > Sent: Wednesday, July 27, 2016 11:46 PM
> > > > > To: edk2-devel@lists.01.org
> > > > > Cc: Michael Kinney <michael.d.kinney@intel.com>; Jiewen Yao
> > > > > <jiewen.yao@intel.com>; Liming Gao <liming.gao@intel.com>
> > > > > Subject: [edk2] [PATCH] MdePkg: Add DmaRemappingReportingTable.h
> > > > >
> > > > > DMA Remapping Reporting (DMAR) ACPI table definitions from
> > > > > Intel(R) Virtualization
> > > > Technology for Directed I/O (VT-D) Architecture Specification v2.4
> > > > dated June
> > > 2016.
> > > > >
> > > > > This replaces the DMARemappingReportingTable.h from
> > > > > EdkCompatibilityPkg\Foundation\Include\IndustryStandard
> > > > >
> > > > > Cc: Michael Kinney <michael.d.kinney@intel.com>
> > > > > Cc: Liming Gao <liming.gao@intel.com>
> > > > > Cc: Jiewen Yao <jiewen.yao@intel.com>
> > > > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > > > Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
> > > > > ---
> > > > >  .../IndustryStandard/DmaRemappingReportingTable.h  | 254
> > > > > +++++++++++++++++++++
> > > > >  1 file changed, 254 insertions(+)  create mode 100644
> > > > > MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
> > > > >
> > > > > diff --git
> > > > > a/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
> > > > > b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
> > > > > new file mode 100644
> > > > > index 0000000..691aea0
> > > > > --- /dev/null
> > > > > +++ b/MdePkg/Include/IndustryStandard/DmaRemappingReportingTable.h
> > > > > @@ -0,0 +1,254 @@
> > > > > +/** @file
> > > > > +  DMA Remapping Reporting (DMAR) ACPI table definition from
> > > > > +Intel(R)
> > > > > +  Virtualization Technology for Directed I/O (VT-D) Architecture
> > > Specification.
> > > > > +
> > > > > +  Copyright (c) 2016, Intel Corporation. All rights reserved.<BR>
> > > > > + This program and the accompanying materials  are licensed and
> > > > > + made available under the terms and conditions of the BSD License
> > > > > + which accompanies this distribution.  The full text of the
> > > > > + license may be found at
> > > > > + http://opensource.org/licenses/bsd-license.php
> > > > > +
> > > > > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > > > > + BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> > > EITHER
> > > > > + EXPRESS OR
> > > > IMPLIED.
> > > > > +
> > > > > +  @par Revision Reference:
> > > > > +    - Intel(R) Virtualization Technology for Directed I/O (VT-D) Architecture
> > > > > +      Specification v2.4, Dated June 2016.
> > > > > +
> > > > > +
> > > http://www.intel.com/content/dam/www/public/us/en/documents/produc
> > > > > + t- sp ecifications/vt-directed-io-spec.pdf
> > > > > +
> > > > > +  @par Glossary:
> > > > > +    - HPET - High Precision Event Timer
> > > > > +    - NUMA - Non-uniform Memory Access **/ #ifndef
> > > > > +_DMA_REMAPPING_REPORTING_TABLE_H_ #define
> > > > > +_DMA_REMAPPING_REPORTING_TABLE_H_
> > > > > +
> > > > > +#pragma pack(1)
> > > > > +
> > > > > +///
> > > > > +/// DMA Remapping Reporting Table Revision ///
> > > > > +#define EFI_ACPI_DMAR_DESCRIPTION_TABLE_REVISION   0x01
> > > > > +
> > > > > +///
> > > > > +/// DMA-Remapping Reporting ACPI Table definitions from section
> > > > > +8.1 ///@{
> > > > > +#define EFI_ACPI_DMAR_TABLE_FLAGS_INTR_REMAP_SET            BIT0
> > > > > +#define EFI_ACPI_DMAR_TABLE_FLAGS_X2APIC_OPT_OUT_SET        BIT1
> > > > > +///@}
> > > > > +
> > > > > +///
> > > > > +/// Remapping Structure Types definitions from section 8.2 ///@{
> > > > > +#define EFI_ACPI_DMAR_TYPE_DRHD   0x00
> > > > > +#define EFI_ACPI_DMAR_TYPE_RMRR   0x01
> > > > > +#define EFI_ACPI_DMAR_TYPE_ATSR   0x02
> > > > > +#define EFI_ACPI_DMAR_TYPE_RHSA   0x03
> > > > > +#define EFI_ACPI_DMAR_TYPE_ANDD   0x04
> > > > > +///@}
> > > > > +
> > > > > +///
> > > > > +/// Definition for DMA Remapping Structure Header /// typedef struct {
> > > > > +  UINT16        Type;
> > > > > +  UINT16        Length;
> > > > > +} EFI_ACPI_DMAR_STRUCTURE_HEADER;
> > > > > +
> > > > > +///
> > > > > +/// Definition for DMA-Remapping PCI Path /// typedef struct {
> > > > > +  UINT8         Device;
> > > > > +  UINT8         Function;
> > > > > +} EFI_ACPI_DMAR_PCI_PATH;
> > > > > +
> > > > > +///
> > > > > +/// DMA-Remapping Device Scope Entry Structure definitions from
> > > > > +section
> > > > > +8.3.1 ///@{
> > > > > +#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_ENDPOINT
> > 0x01
> > > > > +#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_PCI_BRIDGE             0x02
> > > > > +#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_IOAPIC                 0x03
> > > > > +#define EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_MSI_CAPABLE_HPET
> > > 0x04
> > > > > +#define
> > > EFI_ACPI_DEVICE_SCOPE_ENTRY_TYPE_ACPI_NAMESPACE_DEVICE
> > > > > +0x05 ///@}
> > > > > +
> > > > > +///
> > > > > +/// Device Scope Structure is defined in section 8.3.1 ///
> > > > > +typedef struct {
> > > > > +  UINT8         Type;
> > > > > +  UINT8         Length;
> > > > > +  UINT16        Reserved2;
> > > > > +  UINT8         EnumerationId;
> > > > > +  UINT8         StartBusNumber;
> > > > > +} EFI_ACPI_DMAR_DEVICE_SCOPE_STRUCTURE_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  DMA-remapping hardware unit definition (DRHD) structure is
> > > > > +defined in
> > > > > +  section 8.3. This uniquely represents a remapping hardware unit
> > > > > +present
> > > > > +  in the platform. There must be at least one instance of this
> > > > > +structure
> > > > > +  for each PCI segment in the platform.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
> > > > > +  /**
> > > > > +    - Bit[0]: INCLUDE_PCI_ALL
> > > > > +              - If Set, this remapping hardware unit has under its scope all
> > > > > +                PCI compatible devices in the specified Segment, except
> devices
> > > > > +                reported under the scope of other remapping hardware units for
> > > > > +                the same Segment.
> > > > > +              - If Clear, this remapping hardware unit has under its scope
> only
> > > > > +                devices in the specified Segment that are explicitly
> identified
> > > > > +                through the DeviceScope field.
> > > > > +    - Bits[7:1] Reserved.
> > > > > +  **/
> > > > > +  UINT8                           Flags;
> > > > > +  UINT8                           Reserved;
> > > > > +  ///
> > > > > +  /// The PCI Segment associated with this unit.
> > > > > +  ///
> > > > > +  UINT16                          SegmentNumber;
> > > > > +  ///
> > > > > +  /// Base address of remapping hardware register-set for this unit.
> > > > > +  ///
> > > > > +  UINT64                          RegisterBaseAddress;
> > > > > +} EFI_ACPI_DMAR_DRHD_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  Reserved Memory Region Reporting Structure (RMRR) is described
> > > > > +in section 8.4
> > > > > +  Reserved memory ranges that may be DMA targets may be reported
> > > > > +through the
> > > > > +  RMRR structures, along with the devices that requires access to
> > > > > +the specified
> > > > > +  reserved memory region.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
> > > > > +  UINT8                           Reserved[2];
> > > > > +  ///
> > > > > +  /// PCI Segment Number associated with devices identified
> > > > > +through
> > > > > +  /// the Device Scope field.
> > > > > +  ///
> > > > > +  UINT16                          SegmentNumber;
> > > > > +  ///
> > > > > +  /// Base address of 4KB-aligned reserved memory region
> > > > > +  ///
> > > > > +  UINT64                          ReservedMemoryRegionBaseAddress;
> > > > > +  /**
> > > > > +    Last address of the reserved memory region. Value in this field must be
> > > > > +    greater than the value in Reserved Memory Region Base Address field.
> > > > > +    The reserved memory region size (Limit - Base + 1) must be an integer
> > > > > +    multiple of 4KB.
> > > > > +  **/
> > > > > +  UINT64                          ReservedMemoryRegionLimitAddress;
> > > > > +} EFI_ACPI_DMAR_RMRR_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  Root Port ATS Capability Reporting (ATSR) structure is defined
> > > > > +in section
> > > 8.5.
> > > > > +  This structure is applicable only for platforms supporting
> > > > > +Device-TLBs as
> > > > > +  reported through the Extended Capability Register. For each PCI
> > > > > +Segment in
> > > > > +  the platform that supports Device-TLBs, BIOS provides an ATSR
> > > > > +structure. The
> > > > > +  ATSR structures identifies PCI-Express Root-Ports supporting
> > > > > +Address
> > > > > +  Translation Services (ATS) transactions. Software must enable
> > > > > +ATS on endpoint
> > > > > +  devices behind a Root Port only if the Root Port is reported as
> > > > > +supporting
> > > > > +  ATS transactions.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
> > > > > +  /**
> > > > > +    - Bit[0]: ALL_PORTS:
> > > > > +              - If Set, indicates all PCI Express Root Ports in the specified
> > > > > +                PCI Segment supports ATS transactions.
> > > > > +              - If Clear, indicates ATS transactions are supported only on
> > > > > +                Root Ports identified through the Device Scope field.
> > > > > +    - Bits[7:1] Reserved.
> > > > > +  **/
> > > > > +  UINT8                           Flags;
> > > > > +  UINT8                           Reserved;
> > > > > +  ///
> > > > > +  /// The PCI Segment associated with this ATSR structure
> > > > > +  ///
> > > > > +  UINT16                          SegmentNumber;
> > > > > +} EFI_ACPI_DMAR_ATSR_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  Remapping Hardware Static Affinity (RHSA) is an optional
> > > > > +structure defined
> > > > > +  in section 8.6. This is intended to be used only on NUMA
> > > > > +platforms with
> > > > > +  Remapping hardware units and memory spanned across multiple nodes.
> > > > > +  When used, there must be a RHSA structure for each Remapping
> > > > > +hardware unit
> > > > > +  reported through DRHD structure.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
> > > > > +  UINT8                           Reserved[4];
> > > > > +  ///
> > > > > +  /// Register Base Address of this Remap hardware unit reported
> > > > > +in the
> > > > > +  /// corresponding DRHD structure.
> > > > > +  ///
> > > > > +  UINT64                          RegisterBaseAddress;
> > > > > +  ///
> > > > > +  /// Proximity Domain to which the Remap hardware unit
> > > > > +identified by the
> > > > > +  /// Register Base Address field belongs.
> > > > > +  ///
> > > > > +  UINT32                          ProximityDomain;
> > > > > +} EFI_ACPI_DMAR_RHSA_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  An ACPI Name-space Device Declaration (ANDD) structure is
> > > > > +defined in section
> > > > > +  8.7 and uniquely represents an ACPI name-space enumerated
> > > > > +device capable of
> > > > > +  issuing DMA requests in the platform. ANDD structures are used
> > > > > +in conjunction
> > > > > +  with Device-Scope entries of type ACPI_NAMESPACE_DEVICE.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DMAR_STRUCTURE_HEADER  Header;
> > > > > +  UINT8                           Reserved[3];
> > > > > +  /**
> > > > > +    Each ACPI device enumerated through an ANDD structure must
> > > > > +have a
> > > unique
> > > > > +    value for this field. To report an ACPI device with ACPI Device Number
> > > > > +    value of X, under the scope of a DRHD unit, a Device-Scope entry of
> > type
> > > > > +    ACPI_NAMESPACE_DEVICE is used with value of X in the
> > > > > + Enumeration ID
> > > field.
> > > > > +    The Start Bus Number and Path fields in the Device-Scope together
> > > > > +    provides the 16-bit source-id allocated by platform for the ACPI device.
> > > > > +  **/
> > > > > +  UINT8                           AcpiDeviceNumber;
> > > > > +} EFI_ACPI_DMAR_ANDD_HEADER;
> > > > > +
> > > > > +/**
> > > > > +  DMA Remapping Reporting Structure Header as defined in section
> > > > > +8.1
> > > > > +  This header will be followed by list of Remapping Structures listed below
> > > > > +    - DMA Remapping Hardware Unit Definition (DRHD)
> > > > > +    - Reserved Memory Region Reporting (RMRR)
> > > > > +    - Root Port ATS Capability Reporting (ATSR)
> > > > > +    - Remapping Hardware Static Affinity (RHSA)
> > > > > +    - ACPI Name-space Device Declaration (ANDD)
> > > > > +  These structure types must by reported in numerical order.
> > > > > +  i.e., All remapping structures of type 0 (DRHD) enumerated
> > > > > +before remapping
> > > > > +  structures of type 1 (RMRR), and so forth.
> > > > > +**/
> > > > > +typedef struct {
> > > > > +  EFI_ACPI_DESCRIPTION_HEADER     Header;
> > > > > +  /**
> > > > > +    This field indicates the maximum DMA physical addressability
> > > > > +supported
> > > by
> > > > > +    this platform. The system address map reported by the BIOS
> > > > > + indicates
> > > what
> > > > > +    portions of this addresses are populated. The Host Address
> > > > > + Width (HAW)
> > > of
> > > > > +    the platform is computed as (N+1), where N is the value reported in this
> > > > > +    field.
> > > > > +    For example, for a platform supporting 40 bits of physical
> > addressability,
> > > > > +    the value of 100111b is reported in this field.
> > > > > +  **/
> > > > > +  UINT8                           HostAddressWidth;
> > > > > +  /**
> > > > > +    - Bit[0]:   INTR_REMAP - If Clear, the platform does not support
> > interrupt
> > > > > +                remapping. If Set, the platform supports interrupt remapping.
> > > > > +    - Bit[1]:   X2APIC_OPT_OUT - For firmware compatibility reasons,
> > > platform
> > > > > +                firmware may Set this field to request system software to opt
> > > > > +                out of enabling Extended xAPIC (X2APIC) mode. This field is
> > > > > +                valid only when the INTR_REMAP field (bit 0) is Set.
> > > > > +    - Bits[7:2] Reserved.
> > > > > +  **/
> > > > > +  UINT8                           Flags;
> > > > > +  UINT8                           Reserved[10];
> > > > > +} EFI_ACPI_DMAR_HEADER;
> > > > > +
> > > > > +#pragma pack()
> > > > > +
> > > > > +#endif
> > > > > --
> > > > > 2.9.0.windows.1
> > > > >
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > >
> > > >
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel