Hi Dan Which driver are you referring to? If it is the dax driver than it is always loaded - we see /dev/dax0. If you refer to the user space application which called the mmap on the dax device then this application is not running anymore. We used this application to get the virtual address mapping(doing mmap on dax) and then by going over the proc pagemap we got the physical address. After that the application terminates and we pass this physical address to our kernel thread . Then from the kernel thread we access this range by using phys_to_virt (we know the physical so we convert it virtual). As far as I know once in kernel space all address range should be mapped to the kernel page tables in 64 bit architecture ofcourse, thus accessible using phys_to_virt. Is this a wrong assumption when dealing with NVRAM? If I know the physical address of the nvram isn't it accessible from the kernel using the simple conversion of phys_to_virt?
Thanks Oren On 10 January 2018 at 01:05, Dan Williams <dan.j.willi...@intel.com> wrote: > On Tue, Jan 9, 2018 at 2:25 PM, Oren Berman <o...@lightbitslabs.com> > wrote: > > Hi > > > > I would like to know if you encountered such a problem. > > > > We are accessing the nvram as memory from withing the kernel. > > By mapping dax device and reading its mapping we can know the physical > > address of the nvram. > > As a result we can access this address range in the kernel by calling > > phys_to_virt. > > This is working in most case but we saw some issue that after reboot, > when > > trying to read the info saved > > on the nvram before the power off, one kernel thread was able to read > > from this range but another kernel thread got page fault. > > > > This is not recreated very easily and we need run many reboot sequences > to > > get this failure again. > > Are you aware of any mapping issues of nvram to kernel space? > > When are you using phys_to_virt()? That will only return a valid > virtual address as long as the driver is loaded. It sounds like you > may be losing a race with the driver setting up or tearing down the > mappings. > _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
