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 <[email protected]>; Tim Lewis > <[email protected]>; > Kinney, Michael D <[email protected]>; Laszlo Ersek > <[email protected]>; edk2- > [email protected] <[email protected]> > Cc: Yao, Jiewen <[email protected]>; Gao, Liming <[email protected]>; > Mudusuru, > Giri P <[email protected]> > 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 <[email protected]>; Tim Lewis > > <[email protected]>; Kinney, Michael D <[email protected]>; > > Laszlo Ersek <[email protected]>; [email protected] <edk2- > > [email protected]> > > Cc: Yao, Jiewen <[email protected]>; Gao, Liming <[email protected]> > > 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:[email protected]] On Behalf Of > > Mudusuru, Giri P > > Sent: Thursday, July 28, 2016 10:59 AM > > To: Tim Lewis <[email protected]>; Kinney, Michael D > > <[email protected]>; Laszlo Ersek <[email protected]>; edk2- > > [email protected] <[email protected]> > > Cc: Yao, Jiewen <[email protected]>; Gao, Liming <[email protected]> > > 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:[email protected]] > > > Sent: Thursday, July 28, 2016 9:55 AM > > > To: Kinney, Michael D <[email protected]>; Laszlo Ersek > > > <[email protected]>; Mudusuru, Giri P <[email protected]>; > > > edk2- [email protected] <[email protected]> > > > Cc: Yao, Jiewen <[email protected]>; Gao, Liming > > > <[email protected]> > > > 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:[email protected]] > > > Sent: Thursday, July 28, 2016 9:51 AM > > > To: Tim Lewis <[email protected]>; Laszlo Ersek > > > <[email protected]>; Mudusuru, Giri P <[email protected]>; > > > [email protected] <edk2- [email protected]>; Kinney, Michael D > > > <[email protected]> > > > Cc: Yao, Jiewen <[email protected]>; Gao, Liming > > > <[email protected]> > > > 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:[email protected]] On Behalf > > > > Of Tim Lewis > > > > Sent: Thursday, July 28, 2016 9:42 AM > > > > To: Laszlo Ersek <[email protected]>; Mudusuru, Giri P > > > > <[email protected]>; [email protected] > > > > <[email protected]> > > > > Cc: Kinney, Michael D <[email protected]>; Yao, Jiewen > > > > <[email protected]>; Gao, Liming <[email protected]> > > > > 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:[email protected]] > > > > Sent: Thursday, July 28, 2016 9:29 AM > > > > To: Tim Lewis <[email protected]>; Giri P Mudusuru > > > > <[email protected]>; [email protected] > > > > <[email protected]> > > > > Cc: Michael Kinney <[email protected]>; Jiewen Yao > > > > <[email protected]>; Liming Gao <[email protected]> > > > > 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 <[email protected]> > > > > 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 <[email protected]> > > > > Reviewed-by: Gao Liming <[email protected]> > > > > > > > > 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 <[email protected]> > > > > 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" <[email protected]> > > > > Reviewed-by: "Jiewen Yao" <[email protected]> > > > > > > > > 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 <[email protected]> > > > > 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" <[email protected]> > > > > Reviewed: "Zhang, Chao B" <[email protected]> > > > > > > > > > > > > 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 <[email protected]> > > > > 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 <[email protected]> > > > > Reviewed-by: Yao Jiewen <[email protected]> > > > > Reviewed-by: Liming Gao <[email protected]> > > > > > > > > MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h > > > > | > > > > 25 > > > > ++++++++++++++++++-- > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > > > (5) > > > > > > > > commit 9f0b995e64b8d6beec2edef7fdddc3374e624e42 > > > > Author: Sami Mujawar <[email protected]> > > > > 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 <[email protected]> > > > > Reviewed-by: Yao Jiewen <[email protected]> > > > > Reviewed-by: Liming Gao <[email protected]> > > > > > > > > MdePkg/Include/IndustryStandard/DebugPort2Table.h | 6 ++++++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > (6) > > > > > > > > commit 6a0d24221241bb1b13bafc7b2d264240d19d2993 > > > > Author: Jiewen Yao <[email protected]> > > > > 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" <[email protected]> > > > > Cc: "Kinney, Michael D" <[email protected]> > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > > Signed-off-by: "Yao, Jiewen" <[email protected]> > > > > Reviewed-by: "Gao, Liming" <[email protected]> > > > > > > > > MdePkg/Include/IndustryStandard/WindowsSmmSecurityMitigationTable.h > > > > | > > > > 39 > > > > ++++++++++++++++++++ > > > > 1 file changed, 39 insertions(+) > > > > > > > > Thanks > > > > Laszlo > > > > > > > > > -----Original Message----- > > > > > From: edk2-devel [mailto:[email protected]] On > > > > > Behalf Of Giri P Mudusuru > > > > > Sent: Wednesday, July 27, 2016 11:46 PM > > > > > To: [email protected] > > > > > Cc: Michael Kinney <[email protected]>; Jiewen Yao > > > > > <[email protected]>; Liming Gao <[email protected]> > > > > > 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 <[email protected]> > > > > > Cc: Liming Gao <[email protected]> > > > > > Cc: Jiewen Yao <[email protected]> > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > > > Signed-off-by: Giri P Mudusuru <[email protected]> > > > > > --- > > > > > .../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 > > > > > [email protected] > > > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > _______________________________________________ > > > > > edk2-devel mailing list > > > > > [email protected] > > > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > > > > > > > > _______________________________________________ > > > > edk2-devel mailing list > > > > [email protected] > > > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
