Messages in this thread | | | Subject | Re: [RFCv2 08/16] KVM: Use GUP instead of copy_from/to_user() to access guest memory | From | John Hubbard <> | Date | Mon, 26 Oct 2020 13:52:07 -0700 |
| |
On 10/26/20 6:28 AM, Matthew Wilcox wrote: > On Sun, Oct 25, 2020 at 09:44:07PM -0700, John Hubbard wrote: >> On 10/25/20 9:21 PM, Matthew Wilcox wrote: >>> I don't think the page pinning approach is ever valid. For file >> >> Could you qualify that? Surely you don't mean that the entire pin_user_pages >> story is a waste of time--I would have expected you to make more noise >> earlier if you thought that, yes? > > I do think page pinning is the wrong approach for everything. I did say
Not *everything*, just "pinning for DMA", right? Because I don't recall any viable solutions for Direct IO that avoided gup/pup!
Also, back to Case 5: I *could* create a small patchset to change over the very few Case 5 call sites to use "gup, lock_page(), write to page...etc", instead of pup. And also, update pin_user_pages.rst to recommend that approach in similar situations. After all, it's not really a long-term DMA pin, which is really what pin_user_pages*() is intended for.
Would that be something you'd like to see happen? It's certainly easy enough to fix that up. And your retroactive NAK is sufficient motivation to do so.
> so at the time, and I continue to say so when the opportunity presents > itself. But shouting about it constantly only annoys people, so I don't > generally bother. I have other things to work on, and they're productive, > so I don't need to spend my time arguing.
Sure. As a practical matter, I've assumed that page pinning is not going to go away any time soon, so I want it to work properly while it's here. But if there is a viable way to eventually replace dma-pinning with something better, then let's keep thinking about it. I'm glad to help in that area.
thanks, -- John Hubbard NVIDIA
| |