요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
========================================
ACPI considerations for PCI host bridges
========================================
The general rule is that the ACPI namespace should describe everything the
OS might use unless there's another way for the OS to find it [1, 2].
For example, there's no standard hardware mechanism for enumerating PCI
host bridges, so the ACPI namespace must describe each host bridge, the
method for accessing PCI config space below it, the address space windows
the host bridge forwards to PCI (using _CRS), and the routing of legacy
INTx interrupts (using _PRT).
PCI devices, which are below the host bridge, generally do not need to be
described via ACPI. The OS can discover them via the standard PCI
enumeration mechanism, using config accesses to discover and identify
devices and read and size their BARs. However, ACPI may describe PCI
devices if it provides power management or hotplug functionality for them
or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.
ACPI resource description is done via _CRS objects of devices in the ACPI
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesn't have
a driver for the device [3]. That's important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.
Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
reserving address space. The static tables are for things the OS needs to
know early in boot, before it can parse the ACPI namespace. If a new table
is defined, an old OS needs to operate correctly even though it ignores the
table. _CRS allows that because it is generic and understood by the old
OS; a static table does not.
If the OS is expected to manage a non-discoverable device described via
ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
device's registers are.
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
describe all the address space they consume. This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
itself that are not forwarded to PCI. The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
the device-specific details. The host bridge registers also include ECAM
space, since it is consumed by the host bridge.
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
BIOSes didn't use that bit correctly. The result is that the current ACPI
spec defines Consumer/Producer only for the Extended Address Space
descriptors; the bit should be ignored in the older QWord/DWord/Word
Address Space descriptors. Consequently, OSes have to assume all
QWord/DWord/Word descriptors are windows.
Prior to the addition of Extended Address Space descriptors, the failure of
Consumer/Producer meant there was no way to describe bridge registers in
the PNP0A03/PNP0A08 device itself. The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
know about it.
New architectures should be able to use "Consumer" Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
although a strict interpretation of [6] might prohibit this. Old x86 and
ia64 kernels assume all address space descriptors, including "Consumer"
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.
PNP0C02 "motherboard" devices are basically a catch-all. There's no
programming model for them other than "don't use these resources for
anything else." So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.
The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
unless there's a standard firmware interface for config access, e.g., the
ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
and converts memory accesses into PCI configuration accesses. The spec
defines the ECAM address space layout and functionality; only the base of
the address space is device-specific. An ACPI OS learns the base address
from either the static MCFG table or a _CBA method in the PNP0A03 device.
The MCFG table must describe the ECAM space of non-hot pluggable host
bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
a _CBA method in the PNP0A03 device describes the ECAM space of a
hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
address always corresponds to bus 0, even if the bus range below the bridge
(which is reported via _CRS) doesn't start at 0.
[1] ACPI 6.2, sec 6.1:
For any device that is on a non-enumerable type of bus (for example, an
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
system firmware must supply an _HID object ... for each device to
enable OSPM to do that.
[2] ACPI 6.2, sec 3.7:
The OS enumerates motherboard devices simply by reading through the
ACPI Namespace looking for devices with hardware IDs.
Each device enumerated by ACPI includes ACPI-defined objects in the
ACPI Namespace that report the hardware resources the device could
occupy [_PRS], an object that reports the resources that are currently
used by the device [_CRS], and objects for configuring those resources
[_SRS]. The information is used by the Plug and Play OS (OSPM) to
configure the devices.
[3] ACPI 6.2, sec 6.2:
OSPM uses device configuration objects to configure hardware resources
for devices enumerated via ACPI. Device configuration objects provide
information about current and possible resource requirements, the
relationship between shared resources, and methods for configuring
hardware resources.
When OSPM enumerates a device, it calls _PRS to determine the resource
requirements of the device. It may also call _CRS to find the current
resource settings for the device. Using this information, the Plug and
Play system determines what resources the device should consume and
sets those resources by calling the device’s _SRS control method.
In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
Unless otherwise specified, resources for a device are assumed to be
taken from the nearest matching resource above the device in the device
hierarchy.
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
General Flags: Bit [0] Ignored
Extended Address Space Descriptor (.4)
General Flags: Bit [0] Consumer/Producer:
* 1 – This device consumes this resource
* 0 – This device produces and consumes this resource
[5] ACPI 6.2, sec 19.6.43:
ResourceUsage specifies whether the Memory range is consumed by
this device (ResourceConsumer) or passed on to child devices
(ResourceProducer). If nothing is specified, then
ResourceConsumer is assumed.
[6] PCI Firmware 3.2, sec 4.1.2:
If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware. The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource. For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI bus’s
_CRS. The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
[7] PCI Express 4.0, sec 7.2.2:
For systems that are PC-compatible, or that do not implement a
processor-architecture-specific firmware interface standard that allows
access to the Configuration Space, the ECAM is required as defined in
this section.
[8] PCI Firmware 3.2, sec 4.1.2:
The MCFG table is an ACPI table that is used to communicate the base
addresses corresponding to the non-hot removable PCI Segment Groups
range within a PCI Segment Group available to the operating system at
boot. This is required for the PC-compatible systems.
The MCFG table is only used to communicate the base addresses
corresponding to the PCI Segment Groups available to the system at
boot.
[9] PCI Firmware 3.2, sec 4.1.3:
The _CBA (Memory mapped Configuration Base Address) control method is
an optional ACPI object that returns the 64-bit memory mapped
configuration base address for the hot plug capable host bridge. The
base address returned by _CBA is processor-relative address. The _CBA
control method evaluates to an Integer.
This control method appears under a host bridge object. When the _CBA
method appears under an active host bridge object, the operating system
evaluates this structure to identify the memory mapped configuration
base address corresponding to the PCI Segment Group for the bus number
range specified in _CRS method. An ACPI name space object that contains
the _CBA method must also contain a corresponding _SEG method.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
ACPI namespace의 일반 원칙
1-9다른 방법으로 OS가 발견할 수 있는 대상이 아니라면, OS가 사용할 수 있는 모든 요소를 ACPI namespace가 기술해야 한다는 것이 일반 원칙입니다[1, 2].
.. SPDX-License-Identifier: GPL-2.0
========================================
ACPI considerations for PCI host bridges
========================================
The general rule is that the ACPI namespace should describe everything the
OS might use unless there's another way for the OS to find it [1, 2].
Host bridge와 PCI device 열거
10-23PCI host bridge를 열거하는 표준 hardware mechanism은 없습니다. 따라서 ACPI namespace는 각 host bridge, 그 아래 PCI config space 접근 방법, bridge가 PCI로 전달하는 address-space window(`_CRS`), legacy INTx interrupt routing(`_PRT`)을 기술해야 합니다.
Host bridge 아래의 PCI device는 일반적으로 ACPI로 기술할 필요가 없습니다. OS가 표준 PCI enumeration과 config access를 사용해 device를 식별하고 BAR를 읽고 크기를 파악할 수 있기 때문입니다.
다만 ACPI가 PCI device의 power management나 hotplug 기능을 제공하거나, platform interrupt controller에 연결된 INTx를 `_PRT`로 설명해야 한다면 PCI device를 ACPI namespace에 기술할 수 있습니다.
Host bridge는 ACPI가 필수지만 일반 PCI child device는 config space로 열거합니다.
For example, there's no standard hardware mechanism for enumerating PCI
host bridges, so the ACPI namespace must describe each host bridge, the
method for accessing PCI config space below it, the address space windows
the host bridge forwards to PCI (using _CRS), and the routing of legacy
INTx interrupts (using _PRT).
PCI devices, which are below the host bridge, generally do not need to be
described via ACPI. The OS can discover them via the standard PCI
enumeration mechanism, using config accesses to discover and identify
devices and read and size their BARs. However, ACPI may describe PCI
devices if it provides power management or hotplug functionality for them
or if the device has INTx interrupts connected by platform interrupt
controllers and a _PRT is needed to describe those connections.
_CRS resource와 static table
24-38ACPI resource는 namespace의 device `_CRS` object로 기술합니다[2]. `_CRS`는 일반화된 PCI BAR와 비슷해, OS에 해당 device driver가 없어도 어떤 resource가 소비되는지 알 수 있습니다[3].
이 특성 덕분에 오래된 OS도 알지 못하는 새 device가 있는 system에서 resource conflict를 피하며 올바르게 동작할 수 있습니다. 새 device가 기능하지 않더라도 다른 resource와 겹치지 않게 보호할 수 있습니다.
MCFG, HPET, ECDT 같은 static table은 address space 예약 수단이 아닙니다. 이 table들은 ACPI namespace를 parsing하기 전인 boot 초기부터 OS가 알아야 하는 정보를 전달합니다.
새 static table을 모르는 오래된 OS는 이를 무시하므로 reservation을 보장할 수 없습니다. 반면 `_CRS`는 generic interface여서 오래된 OS도 이해할 수 있습니다.
ACPI resource description is done via _CRS objects of devices in the ACPI
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
_CRS and figure out what resource is being consumed even if it doesn't have
a driver for the device [3]. That's important because it means an old OS
can work correctly even on a system with new devices unknown to the OS.
The new devices might not do anything, but the OS can at least make sure no
resources conflict with them.
Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
reserving address space. The static tables are for things the OS needs to
know early in boot, before it can parse the ACPI namespace. If a new table
is defined, an old OS needs to operate correctly even though it ignores the
table. _CRS allows that because it is generic and understood by the old
OS; a static table does not.
비열거 device와 host bridge resource
39-54ACPI가 기술한 비열거 device를 OS가 관리해야 한다면, 특정 `_HID/_CID`가 bind할 driver를 알려주고 `_CRS`가 OS와 driver에 register 위치를 알려줍니다.
PCI host bridge는 PNP0A03 또는 PNP0A08 device입니다. 그 `_CRS`는 PCI bus로 전달하는 모든 window와 PCI로 전달하지 않는 host bridge 자체 register를 포함해 bridge가 소비하는 전체 address space를 기술해야 합니다.
Host bridge register에는 하위 bus range를 정하는 secondary/subordinate bus register, aperture를 기술하는 window register 등이 포함됩니다. 이는 device-specific이고 architecture로 표준화되지 않았으므로 PNP0A03/PNP0A08 driver는 세부 정보를 담은 `_PRS/_CRS/_SRS`를 통해서만 관리할 수 있습니다.
Host bridge가 소비하는 ECAM space도 host bridge register 범위에 포함됩니다.
Host bridge의 가능·현재·설정 resource를 구분합니다.
If the OS is expected to manage a non-discoverable device described via
ACPI, that device will have a specific _HID/_CID that tells the OS what
driver to bind to it, and the _CRS tells the OS and the driver where the
device's registers are.
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
describe all the address space they consume. This includes all the windows
they forward down to the PCI bus, as well as registers of the host bridge
itself that are not forwarded to PCI. The host bridge registers include
things like secondary/subordinate bus registers that determine the bus
range below the bridge, window registers that describe the apertures, etc.
These are all device-specific, non-architected things, so the only way a
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
the device-specific details. The host bridge registers also include ECAM
space, since it is consumed by the host bridge.
Consumer/Producer 호환성
55-77ACPI는 bridge register를 `Consumer`, bridge aperture를 `Producer`로 구분하는 bit를 정의합니다[4, 5]. 그러나 초기 BIOS가 이 bit를 올바르게 사용하지 않았습니다.
현재 ACPI specification은 Consumer/Producer를 Extended Address Space descriptor에만 정의합니다. 오래된 QWord/DWord/Word Address Space descriptor에서는 이 bit를 무시해야 하므로 OS는 이들 descriptor를 모두 window로 간주해야 합니다.
Extended Address Space descriptor가 추가되기 전에는 PNP0A03/PNP0A08 device 자체에 bridge register를 표현할 방법이 없었습니다. 우회책은 ECAM을 포함한 bridge register를 범용 PNP0C02 device에 기술하는 것이었습니다[6].
ECAM을 제외한 bridge register space는 원래 device-specific이므로 generic PNP0A03/PNP0A08 driver인 `pci_root.c`가 알 필요가 없습니다.
새 architecture는 ECAM을 포함한 bridge register에 PNP0A03의 `Consumer` Extended Address Space descriptor를 사용할 수 있어야 합니다. 다만 오래된 x86과 ia64 kernel은 `Consumer` Extended descriptor까지 모든 address-space descriptor를 window로 간주하므로 이 방식은 안전하지 않습니다.
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
BIOSes didn't use that bit correctly. The result is that the current ACPI
spec defines Consumer/Producer only for the Extended Address Space
descriptors; the bit should be ignored in the older QWord/DWord/Word
Address Space descriptors. Consequently, OSes have to assume all
QWord/DWord/Word descriptors are windows.
Prior to the addition of Extended Address Space descriptors, the failure of
Consumer/Producer meant there was no way to describe bridge registers in
the PNP0A03/PNP0A08 device itself. The workaround was to describe the
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
With the exception of ECAM, the bridge register space is device-specific
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
know about it.
New architectures should be able to use "Consumer" Extended Address Space
descriptors in the PNP0A03 device for bridge registers, including ECAM,
although a strict interpretation of [6] might prohibit this. Old x86 and
ia64 kernels assume all address space descriptors, including "Consumer"
Extended Address Space ones, are windows, so it would not be safe to
describe bridge registers this way on those architectures.
PNP0C02, ECAM, MCFG와 _CBA
78-98PNP0C02 `motherboard` device는 사실상 범용 reservation container입니다. Programming model은 없으며, 기술된 resource를 다른 용도로 사용하지 말라는 의미입니다.
따라서 PNP0C02 `_CRS`는 ACPI namespace의 다른 device object 아래 `_CRS`가 claim하지 않았으면서 OS가 다른 대상에 할당해서는 안 되는 address space를 claim해야 합니다.
PCIe specification은 ia64 SAL처럼 config access를 제공하는 표준 firmware interface가 없는 한 Enhanced Configuration Access Method(`ECAM`)를 요구합니다[7]. Host bridge는 ECAM memory address space를 소비하고 memory access를 PCI configuration access로 변환합니다.
ECAM layout과 기능은 specification으로 정해지고 base address만 device-specific입니다. ACPI OS는 static MCFG table 또는 PNP0A03 device의 `_CBA` method에서 base address를 얻습니다.
MCFG는 hotplug할 수 없는 host bridge의 ECAM space를 기술해야 합니다[8]. Static table인 MCFG는 hotplug로 갱신할 수 없으므로 hot-pluggable host bridge의 ECAM은 PNP0A03 device의 `_CBA`가 기술합니다[9].
MCFG와 `_CBA`에서 base address는 bridge 아래 `_CRS` bus range가 0에서 시작하지 않더라도 항상 bus 0에 대응합니다.
Host bridge의 hotplug 가능 여부에 따라 ACPI interface가 달라집니다.
PNP0C02 "motherboard" devices are basically a catch-all. There's no
programming model for them other than "don't use these resources for
anything else." So a PNP0C02 _CRS should claim any address space that is
(1) not claimed by _CRS under any other device object in the ACPI namespace
and (2) should not be assigned by the OS to something else.
The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
unless there's a standard firmware interface for config access, e.g., the
ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
and converts memory accesses into PCI configuration accesses. The spec
defines the ECAM address space layout and functionality; only the base of
the address space is device-specific. An ACPI OS learns the base address
from either the static MCFG table or a _CBA method in the PNP0A03 device.
The MCFG table must describe the ECAM space of non-hot pluggable host
bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
a _CBA method in the PNP0A03 device describes the ECAM space of a
hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
address always corresponds to bus 0, even if the bus range below the bridge
(which is reported via _CRS) doesn't start at 0.
참고문헌 [1] ACPI 6.2 §6.1, [2] §3.7
99-116[1] ISA bus처럼 열거할 수 없는 종류의 bus에 있는 device는 OSPM이 identifier를 열거할 수 있도록 ACPI system firmware가 각 device의 `_HID` object를 제공해야 합니다.
[2] OS는 hardware ID가 있는 device를 찾도록 ACPI Namespace를 읽어 motherboard device를 열거합니다.
ACPI로 열거되는 각 device에는 가능한 resource를 보고하는 `_PRS`, 현재 사용하는 resource를 보고하는 `_CRS`, resource를 구성하는 `_SRS`가 포함됩니다. Plug and Play OS(OSPM)는 이 정보로 device를 구성합니다.
[1] ACPI 6.2, sec 6.1:
For any device that is on a non-enumerable type of bus (for example, an
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
system firmware must supply an _HID object ... for each device to
enable OSPM to do that.
[2] ACPI 6.2, sec 3.7:
The OS enumerates motherboard devices simply by reading through the
ACPI Namespace looking for devices with hardware IDs.
Each device enumerated by ACPI includes ACPI-defined objects in the
ACPI Namespace that report the hardware resources the device could
occupy [_PRS], an object that reports the resources that are currently
used by the device [_CRS], and objects for configuring those resources
[_SRS]. The information is used by the Plug and Play OS (OSPM) to
configure the devices.
참고문헌 [3] ACPI 6.2 §6.2
117-135OSPM은 device configuration object를 사용해 ACPI로 열거한 device의 hardware resource를 구성합니다. 이 object는 현재와 가능한 resource 요구 사항, 공유 resource 관계, hardware resource 구성 method를 제공합니다.
OSPM은 device를 열거할 때 `_PRS`로 요구 사항을 확인하고 `_CRS`로 현재 설정을 확인할 수 있습니다. Plug and Play system은 이 정보로 device가 소비할 resource를 결정한 뒤 `_SRS` control method를 호출해 설정합니다.
ACPI device는 resource를 소비하거나, 제공하거나, 둘 다 할 수 있습니다. 별도 규정이 없으면 device resource는 device hierarchy에서 위쪽에 있는 가장 가까운 일치 resource에서 가져온다고 간주합니다.
[3] ACPI 6.2, sec 6.2:
OSPM uses device configuration objects to configure hardware resources
for devices enumerated via ACPI. Device configuration objects provide
information about current and possible resource requirements, the
relationship between shared resources, and methods for configuring
hardware resources.
When OSPM enumerates a device, it calls _PRS to determine the resource
requirements of the device. It may also call _CRS to find the current
resource settings for the device. Using this information, the Plug and
Play system determines what resources the device should consume and
sets those resources by calling the device’s _SRS control method.
In ACPI, devices can consume resources (for example, legacy keyboards),
provide resources (for example, a proprietary PCI bridge), or do both.
Unless otherwise specified, resources for a device are assumed to be
taken from the nearest matching resource above the device in the device
hierarchy.
참고문헌 [4] Address Space descriptor, [5] ResourceUsage
136-151[4] QWord/DWord/Word Address Space Descriptor의 General Flags bit 0은 무시합니다. Extended Address Space Descriptor의 bit 0은 Consumer/Producer를 나타냅니다.
Consumer/Producer bit의 의미입니다.
[5] `ResourceUsage`는 memory range가 이 device에 의해 소비되는지(`ResourceConsumer`), child device로 전달되는지(`ResourceProducer`) 지정합니다. 생략하면 `ResourceConsumer`로 간주합니다.
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
General Flags: Bit [0] Ignored
Extended Address Space Descriptor (.4)
General Flags: Bit [0] Consumer/Producer:
* 1 – This device consumes this resource
* 0 – This device produces and consumes this resource
[5] ACPI 6.2, sec 19.6.43:
ResourceUsage specifies whether the Memory range is consumed by
this device (ResourceConsumer) or passed on to child devices
(ResourceProducer). If nothing is specified, then
ResourceConsumer is assumed.
참고문헌 [6] PCI Firmware 3.2 §4.1.2
152-163OS가 MMCFG region reservation을 native하게 이해하지 못한다면 firmware가 해당 region을 예약해야 합니다. MCFG table 또는 `_CBA`가 보고한 address range는 motherboard resource 선언으로 예약해야 합니다.
대부분의 system에서 motherboard resource는 ACPI namespace root의 `\_SB` 아래 `_HID`가 EISAID(PNP0C02)인 node에 위치하며, 이 resource는 root PCI bus의 `_CRS`에서 claim하지 않아야 합니다.
Resource를 Int15 E820 또는 `EFIGetMemoryMap`에서 reserved memory로 반환하는 것은 선택 사항이지만, ACPI에서는 항상 motherboard resource로 보고해야 합니다.
[6] PCI Firmware 3.2, sec 4.1.2:
If the operating system does not natively comprehend reserving the
MMCFG region, the MMCFG region must be reserved by firmware. The
address range reported in the MCFG table or by _CBA method (see Section
4.1.3) must be reserved by declaring a motherboard resource. For most
systems, the motherboard resource would appear at the root of the ACPI
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
the resources in this case should not be claimed in the root PCI bus’s
_CRS. The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.
참고문헌 [7] PCIe 4.0 §7.2.2, [8] PCI Firmware 3.2 §4.1.2
164-179[7] PC-compatible system이거나 configuration space 접근을 허용하는 processor-architecture-specific firmware interface standard가 없는 system은 이 절에 정의된 ECAM을 구현해야 합니다.
[8] MCFG는 boot할 때 OS가 사용할 수 있는 PCI Segment Group 안의 non-hot-removable PCI Segment Group range에 대응하는 base address를 전달하는 ACPI table입니다. PC-compatible system에서는 필수입니다.
MCFG table은 system boot 시 사용할 수 있는 PCI Segment Group의 base address 전달에만 사용합니다.
[7] PCI Express 4.0, sec 7.2.2:
For systems that are PC-compatible, or that do not implement a
processor-architecture-specific firmware interface standard that allows
access to the Configuration Space, the ECAM is required as defined in
this section.
[8] PCI Firmware 3.2, sec 4.1.2:
The MCFG table is an ACPI table that is used to communicate the base
addresses corresponding to the non-hot removable PCI Segment Groups
range within a PCI Segment Group available to the operating system at
boot. This is required for the PC-compatible systems.
The MCFG table is only used to communicate the base addresses
corresponding to the PCI Segment Groups available to the system at
boot.
참고문헌 [9] PCI Firmware 3.2 §4.1.3
180-192`_CBA`(Memory mapped Configuration Base Address)는 hotplug 가능한 host bridge의 64bit memory-mapped configuration base address를 반환하는 선택적 ACPI object입니다. 반환 주소는 processor-relative address이고 method 결과는 Integer입니다.
이 control method는 host bridge object 아래에 위치합니다. Active host bridge에 `_CBA`가 있으면 OS는 이를 평가해 `_CRS`가 지정한 bus-number range의 PCI Segment Group에 대응하는 memory-mapped configuration base address를 식별합니다.
`_CBA` method가 있는 ACPI namespace object에는 대응하는 `_SEG` method도 있어야 합니다.
[9] PCI Firmware 3.2, sec 4.1.3:
The _CBA (Memory mapped Configuration Base Address) control method is
an optional ACPI object that returns the 64-bit memory mapped
configuration base address for the hot plug capable host bridge. The
base address returned by _CBA is processor-relative address. The _CBA
control method evaluates to an Integer.
This control method appears under a host bridge object. When the _CBA
method appears under an active host bridge object, the operating system
evaluates this structure to identify the memory mapped configuration
base address corresponding to the PCI Segment Group for the bus number
range specified in _CRS method. An ACPI name space object that contains
the _CBA method must also contain a corresponding _SEG method.
요약·해설
acpi-info.rst:1-192Host bridge는 표준 hardware enumeration이 없으므로 ACPI가 bridge, config access, forwarding window와 INTx routing을 기술해야 하지만 일반 child PCI device는 config space로 찾을 수 있습니다.
`_CRS`는 오래된 OS도 이해하는 generic reservation 수단이며, ECAM base는 non-hotplug bridge에는 MCFG, hotplug bridge에는 `_CBA`가 전달합니다.