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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux