Hello Mark! On Thursday 20 January 2022 00:23:02 Mark Kettenis wrote: > CAM is just a version of ECAM that only gives you access to the > classic PCI config space (register offsets < 256). This has very > little to do with the classic "mode 1" and "mode 2" config space > access methods of the x86 PCI host bridges.
Interesting... as I have not found anything about CAM in specs... That is why I thought it must be some proprietary, vendor-specific or non-standard access method. "mode 1" is indirect access method and "mode 2" has mapped config space into (io) memory space. But this "CAM" is neither "mode 1" nor "mode 2". That is why it looked suspicious to me. > I don't think there is a > CAM standard at all, but some of the PCI host bridges found on PowerPC > and SPARC hardware implemented a straight mapping of PCI config space > into mmio space like that. Interesting... But at least it looks like that U-Boot does not have support for these kind of hardware. Anyway, is not that mapping in that old hardware of PCI config space into mmio space according to "mode 2" layout? I know that both "mode 1" and "mode 2" are IO-space orientated, but on non-x86 HW there probably does not have to be IO-space and same layout can be used also for memory-space mapping. > It is a little bit strange that crosvm implements CAM instead of ECAM, > but I guess they don't care about passthrough of arbitrary PCIe > devices. And as long as all (emulated) PCIe devices only have > registers with offsets < 256, this will work just fine. > > And yes, you should check that the register offset is limited to > 0..255.
