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-boun...@lists.01.org] On Behalf Of Mudusuru, Giri P Sent: Thursday, July 28, 2016 10:59 AM To: Tim Lewis <tim.le...@insyde.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek <ler...@redhat.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org> Cc: Yao, Jiewen <jiewen....@intel.com>; Gao, Liming <liming....@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.le...@insyde.com] > Sent: Thursday, July 28, 2016 9:55 AM > To: Kinney, Michael D <michael.d.kin...@intel.com>; Laszlo Ersek > <ler...@redhat.com>; Mudusuru, Giri P <giri.p.mudus...@intel.com>; > edk2- de...@lists.01.org <edk2-de...@ml01.01.org> > Cc: Yao, Jiewen <jiewen....@intel.com>; Gao, Liming > <liming....@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.kin...@intel.com] > Sent: Thursday, July 28, 2016 9:51 AM > To: Tim Lewis <tim.le...@insyde.com>; Laszlo Ersek > <ler...@redhat.com>; Mudusuru, Giri P <giri.p.mudus...@intel.com>; > edk2-devel@lists.01.org <edk2- de...@ml01.01.org>; Kinney, Michael D > <michael.d.kin...@intel.com> > Cc: Yao, Jiewen <jiewen....@intel.com>; Gao, Liming > <liming....@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-boun...@lists.01.org] On Behalf > > Of Tim Lewis > > Sent: Thursday, July 28, 2016 9:42 AM > > To: Laszlo Ersek <ler...@redhat.com>; Mudusuru, Giri P > > <giri.p.mudus...@intel.com>; edk2-devel@lists.01.org > > <edk2-de...@ml01.01.org> > > Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Yao, Jiewen > > <jiewen....@intel.com>; Gao, Liming <liming....@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:ler...@redhat.com] > > Sent: Thursday, July 28, 2016 9:29 AM > > To: Tim Lewis <tim.le...@insyde.com>; Giri P Mudusuru > > <giri.p.mudus...@intel.com>; edk2-devel@lists.01.org > > <edk2-de...@ml01.01.org> > > Cc: Michael Kinney <michael.d.kin...@intel.com>; Jiewen Yao > > <jiewen....@intel.com>; Liming Gao <liming....@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.zh...@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.zh...@intel.com> > > Reviewed-by: Gao Liming <liming....@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....@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....@linaro.org> > > Reviewed-by: "Jiewen Yao" <jiewen....@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....@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....@intel.com> > > Reviewed: "Zhang, Chao B" <chao.b.zh...@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.muja...@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.ll...@arm.com> > > Reviewed-by: Yao Jiewen <jiewen....@intel.com> > > Reviewed-by: Liming Gao <liming....@intel.com> > > > > MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h > > | > > 25 > > ++++++++++++++++++-- > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > (5) > > > > commit 9f0b995e64b8d6beec2edef7fdddc3374e624e42 > > Author: Sami Mujawar <sami.muja...@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.ll...@arm.com> > > Reviewed-by: Yao Jiewen <jiewen....@intel.com> > > Reviewed-by: Liming Gao <liming....@intel.com> > > > > MdePkg/Include/IndustryStandard/DebugPort2Table.h | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > (6) > > > > commit 6a0d24221241bb1b13bafc7b2d264240d19d2993 > > Author: Jiewen Yao <jiewen....@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....@intel.com> > > Cc: "Kinney, Michael D" <michael.d.kin...@intel.com> > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: "Yao, Jiewen" <jiewen....@intel.com> > > Reviewed-by: "Gao, Liming" <liming....@intel.com> > > > > MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h > > | > > 39 > > ++++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > Thanks > > Laszlo > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-boun...@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.kin...@intel.com>; Jiewen Yao > > > <jiewen....@intel.com>; Liming Gao <liming....@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.kin...@intel.com> > > > Cc: Liming Gao <liming....@intel.com> > > > Cc: Jiewen Yao <jiewen....@intel.com> > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Giri P Mudusuru <giri.p.mudus...@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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
