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.
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.
Such design has some limitations or opens:
1. how to be backward compatible to existing x86 firmware.
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].
3. No multiple IO windows for each PciRootBridge
Thanks,
Ray
> -----Original Message-----
> From: Ard Biesheuvel <a...@kernel.org>
> Sent: Wednesday, December 20, 2023 5:54 PM
> To: Ni, Ray <ray...@intel.com>
> Cc: devel@edk2.groups.io; lic...@loongson.cn; Kumar, Rahul R
> <rahul.r.ku...@intel.com>; Gerd Hoffmann <kra...@redhat.com>; Leif
> Lindholm <quic_llind...@quicinc.com>; Ard Biesheuvel
> <ardb+tianoc...@kernel.org>; Sami Mujawar <sami.muja...@arm.com>
> Subject: Re: [edk2-devel] [PATCH v4 19/37] UefiCpuPkg: Add MMIO method
> in CpuIo2Dxe
>
> 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 (#112761): https://edk2.groups.io/g/devel/message/112761
Mute This Topic: https://groups.io/mt/103261693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
