Re: [PATCH v6 3/3] mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings

On Tue, May 02, 2023 at 05:09:06PM +0200, David Hildenbrand wrote:

On 02.05.23 15:56, Matthew Rosato wrote:

quoted

On 5/2/23 9:50 AM, Jason Gunthorpe wrote:

quoted

On Tue, May 02, 2023 at 03:47:43PM +0200, David Hildenbrand wrote:

quoted

quoted

Eventually we want to implement a mechanism where we can dynamically pin in response to RPCIT.

Okay, so IIRC we'll fail starting the domain early, that's good. And if we
pin all guest memory (instead of small pieces dynamically), there is little
existing use for file-backed RAM in such zPCI configurations (because memory
cannot be reclaimed either way if it's all pinned), so likely there are no
real existing users.

Right, this is VFIO, the physical HW can't tolerate not having pinned
memory, so something somewhere is always pinning it.

I might have mis-explained above.

With iommufd nesting, we will pin everything upfront as a starting point.

The current usage of vfio type1 iommu for s390 does not pin the entirety of guest memory upfront, it happens as guest RPCITs occur / type1 mappings are made.

... so, after the domain started successfully on the libvirt/QEMU side ? :/

It would be great to confirm that. There might be a BUG in patch #2 (see my
reply to patch #2) that might not allow you to reproduce it right now.

Yes apologies - thank you VERY much for doing this Matthew, but apologies, I
made rather a clanger in patch 2 which would mean fast patch degrading to slow
path would pass even for file-backed.

Will respin a v7 + cc you on that, if you could be so kind as to test that?

--
Thanks,

David / dhildenb