[PATCH] MdePkg: Add DmaRemappingReportingTable.h


Mudusuru, Giri P <giri.p.mudusuru@...>
 

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


Michael D Kinney
 

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