From: "Ni, Ray" <ray.ni@intel.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"lichao@loongson.cn" <lichao@loongson.cn>,
"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
Date: Wed, 20 Dec 2023 12:28:36 +0000 [thread overview]
Message-ID: <MN6PR11MB82441BA5A51B8EE24600E8928C96A@MN6PR11MB8244.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CAMj1kXF=+qy2BF8tLm0Ttjn7+zP99hKb1iTDBvMNSxY8CAhPtg@mail.gmail.com>
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 <ardb@kernel.org>
> Sent: Wednesday, December 20, 2023 5:54 PM
> To: Ni, Ray <ray.ni@intel.com>
> Cc: devel@edk2.groups.io; lichao@loongson.cn; 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
>
> On Wed, 20 Dec 2023 at 10:44, Ni, Ray <ray.ni@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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-12-20 12:28 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 13:09 [edk2-devel] [PATCH v4 00/37] Enable LoongArch virtual machine in edk2 Chao Li
2023-12-12 13:10 ` [edk2-devel] [PATCH v4 01/37] MdePkg: Add the header file named Csr.h for LoongArch64 Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 02/37] MdePkg: Add LoongArch64 FPU function set into BaseCpuLib Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 03/37] MdePkg: Add LoongArch64 exception function set into BaseLib Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 04/37] MdePkg: Add LoongArch64 local interrupt " Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 05/37] MdePkg: Add LoongArch Cpucfg function Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 06/37] MdePkg: Add read stable counter operation for LoongArch Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 07/37] MdePkg: Add CSR " Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 08/37] MdePkg: Add IOCSR " Chao Li
2023-12-12 13:11 ` [edk2-devel] [PATCH v4 09/37] MdePkg: Add a new library named PeiServicesTablePointerLibKs0 Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 10/37] UefiCpuPkg: Add LoongArch64 CPU Timer library Chao Li
2023-12-19 6:29 ` Ni, Ray
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 11/37] UefiCpuPkg: Add CPU exception library for LoongArch Chao Li
2023-12-19 6:30 ` Ni, Ray
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 12/37] UefiCpuPkg: Add CpuMmuLib.h to UefiCpuPkg Chao Li
2023-12-13 5:17 ` Ni, Ray
2023-12-14 2:53 ` Chao Li
[not found] ` <17A0932406FD861E.11381@groups.io>
2023-12-19 1:59 ` Chao Li
2023-12-19 6:29 ` Ni, Ray
2023-12-19 6:56 ` Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 13/37] UefiCpuPkg: Add LoongArch64CpuMmuLib " Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 14/37] UefiCpuPkg: Add multiprocessor library for LoongArch64 Chao Li
2023-12-19 6:30 ` Ni, Ray
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 15/37] UefiCpuPkg: Add CpuDxe driver " Chao Li
2023-12-19 6:30 ` Ni, Ray
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 16/37] EmbeddedPkg: Add PcdPrePiCpuIoSize width for LOONGARCH64 Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 17/37] ArmVirtPkg: Move PCD of FDT base address and FDT padding to OvmfPkg Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 18/37] MdePkg: Add a PCD feature flag named PcdPciIoTranslationIsEnabled Chao Li
2023-12-12 13:12 ` [edk2-devel] [PATCH v4 19/37] UefiCpuPkg: Add MMIO method in CpuIo2Dxe Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 20/37] ArmVirtPkg: Enable UefiCpuPkg version CpuIo2Dxe Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 21/37] OvmfPkg/RiscVVirt: " Chao Li
2023-12-20 7:01 ` Sunil V L
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 22/37] OvmfPkg/RiscVVirt: Remove PciCpuIo2Dxe from RiscVVirt Chao Li
2023-12-20 7:02 ` Sunil V L
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 23/37] ArmVirtPkg: Move the FdtSerialPortAddressLib to OvmfPkg Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 24/37] ArmVirtPkg: Move the PcdTerminalTypeGuidBuffer into OvmfPkg Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 25/37] ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkg Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 26/37] OvmfPkg/LoongArchVirt: Add stable timer driver Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 27/37] OvmfPkg/LoongArchVirt: Add a NULL library named CollectApResouceLibNull Chao Li
2023-12-12 13:13 ` [edk2-devel] [PATCH v4 28/37] OvmfPkg/LoongArchVirt: Add serial port hook library Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 29/37] OvmfPkg/LoongArchVirt: Add the early serial port output library Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 30/37] OvmfPkg/LoongArchVirt: Add real time clock library Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 31/37] OvmfPkg/LoongArchVirt: Add NorFlashQemuLib Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 32/37] OvmfPkg/LoongArchVirt: Add FdtQemuFwCfgLib Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 33/37] OvmfPkg/LoongArchVirt: Add reset system library Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 34/37] OvmfPkg/LoongArchVirt: Support SEC phase Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 35/37] OvmfPkg/LoongArchVirt: Support PEI phase Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 36/37] OvmfPkg/LoongArchVirt: Add build file Chao Li
2023-12-12 13:14 ` [edk2-devel] [PATCH v4 37/37] OvmfPkg/LoongArchVirt: Add self introduction file Chao Li
[not found] ` <17A017B459AD36A8.31409@groups.io>
2023-12-19 12:59 ` [edk2-devel] [PATCH v4 09/37] MdePkg: Add a new library named PeiServicesTablePointerLibKs0 Chao Li
2023-12-19 13:01 ` Chao Li
2023-12-19 13:07 ` 回复: " gaoliming via groups.io
2023-12-20 1:20 ` Chao Li
2023-12-21 7:16 ` 回复: " gaoliming via groups.io
2023-12-21 11:18 ` Chao Li
2023-12-25 1:33 ` 回复: " gaoliming via groups.io
2023-12-27 1:43 ` Chao Li
[not found] ` <17A017C0864F4177.31409@groups.io>
2023-12-19 13:02 ` [edk2-devel] [PATCH v4 18/37] MdePkg: Add a PCD feature flag named PcdPciIoTranslationIsEnabled Chao Li
[not found] ` <17A017C201FEB90D.32321@groups.io>
2023-12-19 13:03 ` [edk2-devel] [PATCH v4 19/37] UefiCpuPkg: Add MMIO method in CpuIo2Dxe Chao Li
2023-12-20 1:57 ` Ni, Ray
2023-12-20 7:41 ` Ard Biesheuvel
2023-12-20 9:44 ` Ni, Ray
2023-12-20 9:54 ` Ard Biesheuvel
2023-12-20 12:28 ` Ni, Ray [this message]
2023-12-20 15:17 ` Ard Biesheuvel
2023-12-21 3:48 ` Chao Li
2023-12-21 7:31 ` Ard Biesheuvel
2023-12-21 12:11 ` Chao Li
2023-12-21 12:31 ` Ard Biesheuvel
2023-12-21 12:41 ` Chao Li
2023-12-21 13:59 ` Ard Biesheuvel
2023-12-22 1:14 ` Chao Li
2023-12-22 2:37 ` Ni, Ray
2023-12-22 9:47 ` Ard Biesheuvel
2023-12-22 9:56 ` Chao Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MN6PR11MB82441BA5A51B8EE24600E8928C96A@MN6PR11MB8244.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox