Re: [PATCH] MdePkg: Add DmaRemappingReportingTable.h

* Re: [PATCH] MdePkg: Add DmaRemappingReportingTable.h
       [not found]             ` <E7F9E664687D4149BABC1AC3FB77629E642A3746@ORSMSX104.amr.corp.intel.com>
@ 2016-08-01 16:52               ` Mudusuru, Giri P
  2016-08-01 17:05                 ` Kinney, Michael D
  0 siblings, 1 reply; 2+ messages in thread
From: Mudusuru, Giri P @ 2016-08-01 16:52 UTC (permalink / raw)
  To: Rothman, Michael A, Tim Lewis, Kinney, Michael D, Laszlo Ersek,
	edk2-devel@lists.01.org
  Cc: Yao, Jiewen, Gao, Liming, Mudusuru, Giri P

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

^ permalink raw reply	[flat|nested] 2+ messages in thread