On Tue, 1 Feb 2022 at 23:51, Alex Williamson <alex.william...@redhat.com> wrote: > > On Tue, 1 Feb 2022 21:24:08 +0000 > Jag Raman <jag.ra...@oracle.com> wrote: > > The PCIBus data structure already has address_space_mem and > > address_space_io to contain the BAR regions of devices attached > > to it. I understand that these two PCIBus members form the > > PCI address space. > > These are the CPU address spaces. When there's no IOMMU, the PCI bus is > identity mapped to the CPU address space. When there is an IOMMU, the > device address space is determined by the granularity of the IOMMU and > may be entirely separate from address_space_mem.
Note that those fields in PCIBus are just whatever MemoryRegions the pci controller model passed in to the call to pci_root_bus_init() or equivalent. They may or may not be specifically the CPU's view of anything. (For instance on the versatilepb board, the PCI controller is visible to the CPU via several MMIO "windows" at known addresses, which let the CPU access into the PCI address space at a programmable offset. We model that by creating a couple of container MRs which we pass to pci_root_bus_init() to be the PCI memory and IO spaces, and then using alias MRs to provide the view into those at the guest-programmed offset. The CPU sees those windows, and doesn't have direct access to the whole PCIBus::address_space_mem.) I guess you could say they're the PCI controller's view of the PCI address space ? We have a tendency to be a bit sloppy with use of AddressSpaces within QEMU where it happens that the view of the world that a DMA-capable device matches that of the CPU, but conceptually they can definitely be different, especially in the non-x86 world. (Linux also confuses matters here by preferring to program a 1:1 mapping even if the hardware is more flexible and can do other things. The model of the h/w in QEMU should support the other cases too, not just 1:1.) > I/O port space is always the identity mapped CPU address space unless > sparse translations are used to create multiple I/O port spaces (not > implemented). I/O port space is only accessed by the CPU, there are no > device initiated I/O port transactions, so the address space relative > to the device is irrelevant. Does the PCI spec actually forbid any master except the CPU from issuing I/O port transactions, or is it just that in practice nobody makes a PCI device that does weird stuff like that ? thanks -- PMM
