On Wed, 20 Dec 2023 at 13:28, Ni, Ray <ray...@intel.com> wrote: > > Thanks for pointing it out. > I found it in ACPI spec that tells how to use "Resource Type Specific Flags" > to describe a MEM resource while maps to IO, > and an IO resource while maps to MEM. > > I assume that the IO port accesses are all from PCI device drivers.
They are all from/to PCI endpoints, and typically by a dedicated driver. But there are other ways to access I/O ports as well: for instance, the 'mm' tool in the UEFI shell can be used to access port I/O directly, and this is implemented using the CpuIo2 protocol. CpuIo2 is used in most generic code that needs to perform port I/O afaict. > Then, we can change the PciHostBridgeLib lib interface to add a new field > Io2Mmio aperture > to PCI_ROOT_BRIDGE indicating the mapping from IO to MMIO? > > If Io2Mmio aperture is valid, any IO access is translated by PciHostBridgeDxe > driver to MMIO access. > The CPU is typically the agent that performs the access (disregarding peer-to-peer, which does not work at all with translation), so I'd say that the MMIO access performed by the CPU is translated to port I/O, not the other way around. Currently, PciHostBridgeDxe is generic code which performs all port I/O via CpuIo2, and I am not convinced this really needs to change. Note that this has been working on ARM for almost 10 years now. I used to travel to UEFI plugfests with a bag of PCIe plugin cards, including ones with serial ports that can only work if port I/O is implemented correctly. I am open to exploring different ways to solve this problem, but please be aware that in my opinion, this problem already has a working solution. > Such design has some limitations or opens: > 1. how to be backward compatible to existing x86 firmware. We'd still need an abstraction that performs port I/O, which would be implemented using io access instructions on x86. Basically, what CpuIo2 does today. > 2. Is the IO window the same as MMIO window? Can IO window and MMIO window > use different strides? E.g.: IO[0-0x10] maps to MMIO[0x100 - 0x120]. That is an excellent question. I don't know the answer, but all implementations I have been involved in use a 1:1 stride between MMIO and port IO > 3. No multiple IO windows for each PciRootBridge > Support for port IO is not mandatory in PCIe, and very few endpoints actually require it (only legacy PCIe endpoints are permitted to rely on them iirc). Having a single port I/O resource window per host bridge does not seem like a big issue to me. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112762): https://edk2.groups.io/g/devel/message/112762 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] -=-=-=-=-=-=-=-=-=-=-=-
