On 3/22/20 1:10 AM, Leon Romanovsky wrote:
On Sat, Mar 21, 2020 at 06:55:05PM -0300, Jason Gunthorpe wrote:
On Sat, Mar 21, 2020 at 10:27:46AM -0700, Ralph Campbell wrote:
On 3/21/20 2:00 AM, Leon Romanovsky wrote:
On Fri, Mar 20, 2020 at 05:31:05PM -0700, Ralph Campbell wrote:
This series adds basic self tests for HMM and are intended for Jason
Gunthorpe's rdma tree which has a number of HMM patches applied.
Changes v7 -> v8:
Rebased to Jason's rdma/hmm tree, plus Jason's 6 patch series
"Small hmm_range_fault() cleanups".
Applied a number of changes from Jason's comments.
Changes v6 -> v7:
Rebased to linux-5.6.0-rc6
Reverted back to just using mmu_interval_notifier_insert() and making
this series only introduce HMM self tests.
Changes v5 -> v6:
Rebased to linux-5.5.0-rc6
Refactored mmu interval notifier patches
Converted nouveau to use the new mmu interval notifier API
Changes v4 -> v5:
Added mmu interval notifier insert/remove/update callable from the
invalidate() callback
Updated HMM tests to use the new core interval notifier API
Changes v1 -> v4:
https://lore.kernel.org/linux-mm/20191104222141.5173-1-rcampbell@xxxxxxxxxx
Ralph Campbell (3):
mm/hmm/test: add selftest driver for HMM
mm/hmm/test: add selftests for HMM
MAINTAINERS: add HMM selftests
MAINTAINERS | 3 +
include/uapi/linux/test_hmm.h | 59 ++
Isn't UAPI folder supposed to be for user-visible interfaces that follow
the rule of non-breaking user space and not for selftests?
Thanks
Most of the other kernel module tests seem to invoke the test as part of the
module load/init. I'm open to moving it if there is a more appropriate location.
Is it even possible to create a user mm_struct and put crazy things in
it soley from a kernel module?
I didn't look very closely of what Ralph did in his patchsets, but from
what I know, if you want in-kernel interface, you use in-kernel module,
if you want to test user visible uapi, you write application. You don't
create new UAPI just to test something in the kernel.
Can kunit help here?
https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
Thanks
Jason
The tests are intended to cover hmm_range_fault() and the migrate_vma_setup(),
migrate_vma_pages(), and migrate_vma_finalize() kernel functions that a device
driver can call to initialize hardware that has its own page tables.
An example is a GPU where the code on the GPU sees the same address space as
code running on the host CPU. This means the test has to have a user process
to create a user process address space and a device driver to simulate some
real device driver. The UAPI is for the user level test program to tell the
kernel module test driver what to do and return results.
The complexity is all around maintaining coherent copies of the user process
page tables while hardware and CPUs are accessing the same physical addresses.
The pages are not pinned as with most I/O so system activity like pagein/pageout,
LRU page reclaim, compaction, and the process calling functions like
mmap(), mprotect(), madvise(), fork(), etc. all update the CPU and device page
tables and would be very hard to duplicate in a kernel level only KUNIT style
of test.