Hi Ray and Ard,
I went out yesterday, sorry for the late reply.
On Wed, 20 Dec 2023 at 02:57, Ni, Ray <ray.ni@intel.com> wrote:It’s new to me that PCI IO (not MMIO) space is accessed through MMIO. PCIE spec defines different TLP types for Memory and I/O request in Transaction Layer chapter. If CpuIoDxe driver issues Memory request to a IO space inside a PCIE device, how does PCIE device claim the TPL packet and response?Hello Ray, On the opposite side of the PCI host bridge, these are all port I/O transactions, and the endpoint is not aware of the distinction between native port I/O and translated port I/O. ARM CPUs do not implement port I/O at all, and so every host bridge that implements port I/O support on the PCI side does so by exposing a special MMIO resource window in the CPU physical address space that gets translated to port I/O accesses at the opposite side.
Ray,
As Ard said, LoongArch also do not implement prot I/O, the MMIO method can covert the addresses to PCI I/O addresses.
Most the unified addressing architecture do not have the IO
instructions, and when they use the IO device, most of them sit
under the PCIe or PCI bus, just like LPC or eSPI, so they will use
the MMIO to access them.
This means that an implementation of the CpuIo2 protocol can only be provided in a meaningful way if there are port I/O capable PCI host bridges in the system, and some bookkeeping is needed to keep track of the mapping between the special MMIO ranges on the CPU side and the port I/O ranges on the PCI side. Note that this is not so different from MMIO translation, where the mapping between MMIO is not 1:1 between CPU and PCI. That said, I am not sure I follow why PcdPciIoTranslationIsEnabled is needed. MMIO translation and IO translation are both properties of the PCI host bridge implementation, so having a system wide PCD for this seems unnecessary to me. But perhaps I missed something?
Ard,
PcdPciIoTranslationIsEnabled is only use for whether to trigger the Ffio read or write, it seem that only x86 or x64 need them, not others.
When I was submitted the patch V2, CpuIo2Dxe was private to
LoongArch, just like Arm and RISC-V. Gerd recommended finding a
better place for ArmPciCpuIo2Dxe so that other ARCH can easily use
it. And then I found the UefiCpuPkg/CpuIo2Dxe might be able to
accommodate the MMIO methods, so I merged them togeter in this
change.
From: Chao Li <lichao@loongson.cn> Sent: Tuesday, December 19, 2023 9:04 PM To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com> Cc: Kumar, Rahul R <rahul.r.kumar@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Leif Lindholm <quic_llindhol@quicinc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Sami Mujawar <sami.mujawar@arm.com> Subject: Re: [edk2-devel] [PATCH v4 19/37] UefiCpuPkg: Add MMIO method in CpuIo2Dxe Hi Ray, Can you please review this patch? Thank you! Thanks, Chao On 2023/12/12 21:12, Chao Li wrote: CpuIo2Dxe only supports IO to access PCI IO. Some ARCH requires MMIO to access PCI IO, add the MMIO access method in CpuIo2Dxe. The MMIO methods depend on PcdPciIoTranslationIsEnabled and PcdPciIoTransLation. The code is referenced from ArmPkg. Build-tested only (with "OvmfPkgX64.dsc"). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584 Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Sami Mujawar <sami.mujawar@arm.com> Signed-off-by: Chao Li <lichao@loongson.cn>