On 2019-01-29 2:50 p.m., Jerome Glisse wrote: > No this is the non HMM case i am talking about here. Fully ignore HMM > in this frame. A GPU driver that do not support or use HMM in anyway > has all the properties and requirement i do list above. So all the points > i was making are without HMM in the picture whatsoever. I should have > posted this a separate patches to avoid this confusion. > > Regarding your HMM question. You can not map HMM pages, all code path > that would try that would trigger a migration back to regular memory > and will use the regular memory for CPU access. > I thought this was the whole point of HMM... And eventually it would support being able to map the pages through the BAR in cooperation with the driver. If not, what's that whole layer for? Why not just have HMM handle this situation? And what struct pages are actually going to be backing these VMAs if it's not using HMM? > Again HMM has nothing to do here, ignore HMM it does not play any role > and it is not involve in anyway here. GPU want to control what object > they allow other device to access and object they do not allow. GPU driver > _constantly_ invalidate the CPU page table and in fact the CPU page table > do not have any valid pte for a vma that is an mmap of GPU device file > for most of the vma lifetime. Changing that would highly disrupt and > break GPU drivers. They need to control that, they need to control what > to do if another device tries to peer map some of their memory. Hence > why they need to implement the callback and decide on wether or not they > allow the peer mapping or use device memory for it (they can decide to > fallback to main memory). But mapping is an operation of the memory/struct pages behind the VMA; not of the VMA itself and I think that's evident by the code in that the only way the VMA layer is involved is the fact that you're abusing vm_ops by adding new ops there and calling it by other layers. Logan
