[PATCH v17 19/35] arch/mm: Export direct {un,}map functions

[David Hildenbrand]

On 01.08.24 00:21, Elliot Berman wrote:
> I wanted to revive this thread based on the mm alignment discussion for
> guest_memfd.
> 
> Gunyah's guest_memfd allocates memory via filemap_alloc_folio, identical
> to KVM's guest_memfd. There's a possiblity of a stage-2 fault when
> memory is donated to guest VM and Linux incidentally tries to access the
> donated memory with an unaligned access. This access will cause kernel
> to panic as it expects to be able to access all memory which has been
> mapped in stage 1. We don't want to disallow unaligned access simply
> because Gunyah drivers are enabled.
> 
> There are two options I see to prevent the stage-2 fault from crashing
> the kernel: we can fix up the stage-2 fault or ensure that Linux has a
> S1 table consistent with S2.
> 
> To do the latter, the obvious solution seemed to be using the
> set_direct_map functions, but you and Christoph have valid concerns
> about exporting this to modules since it's a low-level API. One way to
> avoid exporting the symbols is to make Gunyah a built-in, but I'd like
> to find a better solution.
> 
> One way I can think of is to create a "guest_memfd library" that both
> KVM and Gunyah can use. It abstracts the common bits between the 2 into
> a built-in module and can be the one to call the set_direct_map
> functions. I also think the abstraction will also help keep KVM
> guest_memfd cleaner once we start supporting huge folios (and splitting
> them). Do KVM and mm folks also see value to using a library-fied
> guest_memfd?

Without knowing about any details, this sounds like the right approach 
to me!

-- 
Cheers,

David / dhildenb