On Thu, Apr 4, 2019 at 2:47 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 04/04/2019 06:04, Dan Williams wrote: > > On Wed, Apr 3, 2019 at 9:42 PM Anshuman Khandual > > <anshuman.khandual@xxxxxxx> wrote: > >> > >> > >> > >> On 04/03/2019 07:28 PM, Robin Murphy wrote: > >>> [ +Dan, Jerome ] > >>> > >>> On 03/04/2019 05:30, Anshuman Khandual wrote: > >>>> Arch implementation for functions which create or destroy vmemmap mapping > >>>> (vmemmap_populate, vmemmap_free) can comprehend and allocate from inside > >>>> device memory range through driver provided vmem_altmap structure which > >>>> fulfils all requirements to enable ZONE_DEVICE on the platform. Hence just > >>> > >>> ZONE_DEVICE is about more than just altmap support, no? > >> > >> Hot plugging the memory into a dev->numa_node's ZONE_DEVICE and initializing the > >> struct pages for it has stand alone and self contained use case. The driver could > >> just want to manage the memory itself but with struct pages either in the RAM or > >> in the device memory range through struct vmem_altmap. The driver may not choose > >> to opt for HMM, FS DAX, P2PDMA (use cases of ZONE_DEVICE) where it may have to > >> map these pages into any user pagetable which would necessitate support for > >> pte|pmd|pud_devmap. > > > > What's left for ZONE_DEVICE if none of the above cases are used? > > > >> Though I am still working towards getting HMM, FS DAX, P2PDMA enabled on arm64, > >> IMHO ZONE_DEVICE is self contained and can be evaluated in itself. > > > > I'm not convinced. What's the specific use case. > > The fundamental "roadmap" reason we've been doing this is to enable > further NVDIMM/pmem development (libpmem/Qemu/etc.) on arm64. The fact > that ZONE_DEVICE immediately opens the door to the various other stuff > that the CCIX folks have interest in is a definite bonus, so it would > certainly be preferable to get arm64 on par with the current state of > things rather than try to subdivide the scope further. > > I started working on this from the ZONE_DEVICE end, but got bogged down > in trying to replace my copied-from-s390 dummy hot-remove implementation > with something proper. Anshuman has stepped in to help with hot-remove > (since we also have cloud folks wanting that for its own sake), so is > effectively coming at the problem from the opposite direction, and I'll > be the first to admit that we've not managed the greatest job of meeting > in the middle and coordinating our upstream story; sorry about that :) > > Let me freshen up my devmap patches and post them properly, since that > discussion doesn't have to happen in the context of hot-remove; they're > effectively just parallel dependencies for ZONE_DEVICE. Sounds good. It's also worth noting that Ira's recent patches for supporting get_user_pages_fast() for "longterm" pins relies on PTE_DEVMAP to determine when fast-GUP is safe to proceed, or whether it needs to fall back to slow-GUP. So it really is the case that "devmap" support is an assumption for ZONE_DEVICE.
