On Sun, Nov 12, 2023 at 09:36:23AM +0530, Ajay Garg wrote: > Hi everyone. > > I had written a (hello-world) PCI-driver couple of years back, and was > able to read/write from/to BARs. > I might have a requirement of writing more drivers, so was revisiting > the concepts. > > I have some queries (we can assume no IOMMU is in the picture) : > > 0. > Assertion : During PCI-enumeration, the physical-memory assigned to a > BAR is always contiguous. (Yes/No)? Yes, a BAR defines only a base address and a size, so the region is always contiguous in the PCI bus address space. If there's no IOMMU, it is also contiguous in the CPU physical address space. If there *is* an IOMMU, it is still be contiguous in the PCI bus address space but could be discontiguous in CPU physical address space. > 1. > During ioremap() of BAR-physical memory, does the (mapped) > kernel-virtual-memory correspond to > > * one used in vmalloc(), wherein the > kernel-virtual-address => physical-address > goes through page-tables? > * one used in kmalloc(), wherein the > kernel-virtual-address => physical-address > *in all likelihood* requires only adding an offset? ioremap(), kmalloc(), and vmalloc() all return kernel virtual addresses, and the regions are all virtually contiguous. Space from kmalloc() will be physically contiguous. Space from vmalloc() may not be physically contiguous, and I don't think you can assume ioremap() space is physically contiguous either, although it will be contiguous in the *bus* address space. > 2. > On a related front, how does ioremap() differ from kmap()? kmap() is for highmem (see Documentation/mm/highmem.rst) and has nothing to do with I/O mappings like ioremap(). Very few drivers use it, and I doubt you should use it either. Bjorn
