> > I don't think these last two make any sense. You're doing an MMIO > read from the address bar0_ptr, so this value (0x721f4000001e) came > from the PCI devices. There's no reason to think it's a kernel > virtual address, so you shouldn't call virt_to_phys() on it. Got it, thanks ! > > Yes. You should not need to use virt_to_phys() for PCI MMIO > addresses. Hmm, the thing that started it all :P > > This path is IN the picture. This is exactly the path used by drivers > doing MMIO accesses. > > The CPU does a load from a virtual address (0xffffa0c6c02eb000). The > MMU translates that virtual address to a physical address > (0xe2c20000). Hmm, so I guess the core takeaway is that the virtual-address <=> physical-address mapping is indeed happening as envisioned. It's just that there is no programmatic way to prove/display the mapped physical address, in the case of PCI-MMIO transfers (as virt_to_phys() is not usable in this case). May be, someday it will :) The PCI host bridge decodes that address and generates > a PCIe Memory Read transaction to the bus address 0xe2c20000. > > Your dmesg log should have lines similar to this: > > pci_bus 0000:00: root bus resource [mem 0x7f800000-0xefffffff window] > pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfe7fffff window] > > that show the parts of the CPU physical address space that result in > MMIO to PCI devices. 0xe2c20000 should be inside one of those > windows. > It indeed is, in one of the pci-bridge range. Thanks a ton Bjorn, for taking out the time to provide help, taking the particular program-values as per my run. I am grateful for your patience; nature bless you ! Thanks and Regards, Ajay
