> Let me know if this understanding is correct. > > Or what would you like to do in such situation? > > > > > Not sure how it is really a good idea. > > > > Adaptive locality of memory is still an unsolved problem in Linux, > > sadly. > > > > > > However, the migration stuff should really not be in the driver > > > > either. That should be core DRM logic to manage that. It is so > > > > convoluted and full of policy that all the drivers should be working > > > > in the same way. > > > > > > Completely agreed. Moving migration infrastructures to DRM is part > > > of our plan. We want to first prove of concept with xekmd driver, > > > then move helpers, infrastructures to DRM. Driver should be as easy > > > as implementation a few callback functions for device specific page > > > table programming and device migration, and calling some DRM common > > > functions during gpu page fault. > > > > You'd be better to start out this way so people can look at and > > understand the core code on its own merits. > > The two steps way were agreed with DRM maintainers, see here: https://lore.kernel.org/dri-devel/SA1PR11MB6991045CC69EC8E1C576A715925F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/, bullet 4) After this discussion and the other cross-device HMM stuff I think we should probably push more for common up-front, I think doing this in a driver without considering the bigger picture might not end up extractable, and then I fear the developers will just move onto other things due to management pressure to land features over correctness. I think we have enough people on the list that can review this stuff, and even if the common code ends up being a little xe specific, iterating it will be easier outside the driver, as we can clearly demark what is inside and outside. Dave.
