On Wed, 20 Dec 2023 at 10:44, Ni, Ray <ray...@intel.com> wrote:
>
> Ard,
> Let me try to understand:
>
> 1. CPU does not support IO instructions to access IO ports.
> 2. PCI devices contain IO space.
> 3. A special PCI host bridge can be configured to map a range of MMIO space
> from CPU side to another range of IO space to PCI device side.
>
Correct.
> If above is right, I can imagine what problem Chao is trying to solve.
> There are following facts:
> 4. MdeModulePkg/PciHostBridge driver produces PciRootBridgeIo->Io() service
> which directly calls to CpuIo->Io()
>
> I guess Chao are using MdeModulePkg/PciHostBridge driver.
>
Yes. This driver is widely used on ARM and RISC-V systems.
> I agree with Ard that the proper place to change/hook the IO access is inside
> PciHostBridge driver instead of CpuIo2Dxe if the only IO access is from PCI
> device driver.
>
That is not what I said :-)
I implemented CpuIo2Dxe like this in the past for ARM, and now it
appears we need to generalize this solution for other architectures as
well.
> Then PciHostBridgeDxe driver could be enhanced to honor the MMIO-to-IO
> mapping and only translate the IO request to MMIO which belongs to the IO
> window.
>
The problem is that PI/UEFI has a dedicated global coherency domain
(GCD) for port I/O, so I don't think we can completely hide it in the
PCI driver. But the situation is very different from x86, which has
many well-known port I/O numbers that could either be backed by the
chipset directly or by devices on the PCI bus.
ACPI can already describe this arrangement, e.g., see below, where the
DWordIO window has TypeTranslation, and the range is in the port I/O
domain, but translate and length are in the memory domain. Non-x86
OSes can deal with this natively.
Given that CpuIo2 already exists, and provides a suitable abstraction
(i.e., C functions to perform port I/O where the CPU may not have
native instructions to do so), I think retaining this protocol is
fine, we just need a better way to link it into the existing PCI
infrastructure.
// Root complex resources
Method (_CRS, 0, Serialized) {
Name (RBUF, ResourceTemplate () {
WordBusNumber ( // Bus numbers assigned to this root
ResourceProducer,
MinFixed, MaxFixed, PosDecode,
0, // AddressGranularity
SYNQUACER_PCI_SEG0_BUSNUM_MIN, // Minimum Bus Number
SYNQUACER_PCI_SEG0_BUSNUM_MAX, // Maximum Bus Number
0, // AddressTranslation
SYNQUACER_PCI_SEG0_BUSNUM_RANGE // RangeLength - # of Busses
)
QWordMemory ( // 32-bit BAR Windows
ResourceProducer, PosDecode,
MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x00000000, // Granularity
SYNQUACER_PCI_SEG0_MMIO32_MIN, // Min Base Address
SYNQUACER_PCI_SEG0_MMIO32_MAX, // Max Base Address
SYNQUACER_PCI_SEG0_MMIO32_XLATE, // Translate
SYNQUACER_PCI_SEG0_MMIO32_SIZE // Length
)
QWordMemory ( // 64-bit BAR Windows
ResourceProducer, PosDecode,
MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x00000000, // Granularity
SYNQUACER_PCI_SEG0_MMIO64_MIN, // Min Base Address
SYNQUACER_PCI_SEG0_MMIO64_MAX, // Max Base Address
0x00000000, // Translate
SYNQUACER_PCI_SEG0_MMIO64_SIZE // Length
)
DWordIo ( // IO window
ResourceProducer,
MinFixed,
MaxFixed,
PosDecode,
EntireRange,
0x00000000, // Granularity
SYNQUACER_PCI_SEG0_PORTIO_MIN, // Min Base Address
SYNQUACER_PCI_SEG0_PORTIO_MAX, // Max Base Address
SYNQUACER_PCI_SEG0_PORTIO_MEMBASE, // Translate
SYNQUACER_PCI_SEG0_PORTIO_MEMSIZE, // Length
,
,
,
TypeTranslation
)
}) // Name (RBUF)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112759): https://edk2.groups.io/g/devel/message/112759
Mute This Topic: https://groups.io/mt/103261693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
