On Mon, Mar 16, 2020 at 02:12:01PM +0100, Christoph Hellwig wrote: > On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote: > > > Ok. I had some cleanups like this based of older trees, but if you are > > > active in this area I think I'll let you handle it. > > > > You once said you wanted to loose the weird pfn flags scheme, so > > before putting hmm_range_fault in ODP I planned to do that. > > > > If you have your series someplace send me a URL and I'll look on it > > I have a local branch I just started hacking on, but it is rather broken > based on various discussions we had. But for a basic one I'd suggest > something like: > > - kill HMM_PFN_SPECIAL as it serves no purpose > - split the ->pfns array into an input flags (optional) and an output > pfn (mandtory) one, using new flags for the input side > - replace the output flags/values indirection with a bunch of values > encoded in the high bits of a u64, with the rest used for the pfn Thinking out loud a bit more: - do we really need HMM_PFN_ERROR, or is just a return value from hmm_range_fault enough? - because if it is we don't need output flags at all, and the output array could be struct pages, which would make for a much easier to use API
