> On Jul 28, 2016, at 10:58 AM, Mudusuru, Giri P <giri.p.mudus...@intel.com> > wrote: > > 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. >
Tim, I agree there is a lack of symmetry. I don't have a real strong opinion about this but I'll start with a few thoughts to move the conversation forward. 1) My 1st take is if the item is consumed by multiple sources, especially different operating systems MdePkg is a good landing spot. 2) I'm fine with adding ARM stuff in MdePkg, especially if it things that would consumed by an Application or OS. 3) It would seem a little strange to Include Silicon packages in an EFI Application or OS Loader that was a consumer. 4) If the table is cross referenced by and Industry Standard it seems OK to have it in MdePkg. http://www.acpi.info/links.htm 5) If there is some firmware produced table for AMD-Vi that could get added to the MdePkg also? Thanks, Andrew Fish > 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
