On 19/04/17 11:41 AM, Dan Williams wrote: > No, not quite ;-). I still don't think we should require the non-HMM > to pass NULL for all the HMM arguments. What I like about Logan's > proposal is to have a separate create and register steps dev_pagemap. > That way call paths that don't care about HMM specifics can just turn > around and register the vanilla dev_pagemap. Would you necessarily even need a create step? I was thinking more along the lines that struct dev_pagemap _could_ just be a member in another structure. The caller would set the attributes they needed and pass it to devm_memremap. (Similar to how we commonly do things with struct device, et al). Potentially, that could also get rid of the need for the *data pointer HMM is using to get back the struct hmm_devmem seeing container_of could be used instead. >> Note i won't make any change now on that front but if it make sense >> i am happy to do it as separate patchset on top of HMM. >> >> Also i don't want p2pmem to be an exclusive or with HMM, we will want >> GPU to do peer to peer DMA and thus HMM ZONE_DEVICE pages to support >> this too. > > Yes, this makes sense I think we really just want to distinguish host > memory or not in terms of the dev_pagemap type. That depends though. If unaddressable memory needs different steps to get to the DMA address (ie if it has to setup a gpu window) then we may still need a way to distinguish the two types of non-host memory. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
