Re: [PATCH RFC 0/5] mm/gup: Introduce exclusive GUP pinning

[Elliot Berman <quic_eberman@quicinc.com>]

On Fri, Jun 21, 2024 at 09:25:10AM +0000, Quentin Perret wrote:
> On Friday 21 Jun 2024 at 10:02:08 (+0200), David Hildenbrand wrote:
> > Sure, there might be cases like "pKVM can handle access to private pages in
> > user page mappings", "AMD-SNP will not crash the host if writing to private
> > pages" but there are not factors that really make a difference for a common
> > solution.
> 
> Sure, there isn't much value in differentiating on these things. One
> might argue that we could save one mmap() on the private->shared
> conversion path by keeping all of guest_memfd mapped in userspace
> including private memory, but that's most probably not worth the
> effort of re-designing the whole thing just for that, so let's forget
> that.
> 
> The ability to handle stage-2 faults in the kernel has implications in
> other places however. It means we don't need to punch holes in the
> kernel linear map when donating memory to a guest for example, even with
> 'crazy' access patterns like load_unaligned_zeropad(). So that's good.
> 

The ability to handle stage-2 faults in the kernel is something that's
specific to arm64 pKVM though. We do want to punch holes in the linear
map for Gunyah case. I don't think this is blocking issue. I only want
to point out we can't totally ignore the linear map.

Thanks,
Elliot