Re: [PATCH v8 0/5] Migrate on fault for device pages

[Mika Penttilä]

On 4/25/26 00:23, Matthew Brost wrote:

> On Fri, Apr 24, 2026 at 07:50:37PM +0300, Mika Penttilä wrote:
>> On 4/24/26 19:23, Andrew Morton wrote:
>>
>>> On Tue, 14 Apr 2026 07:12:21 +0300 mpenttil@xxxxxxxxxx wrote:
>>>
>>>> From: Mika Penttilä <mpenttil@xxxxxxxxxx>
>>>>
>>>> Currently, the way device page faulting and migration works
>>>> is not optimal, if you want to do both fault handling and
>>>> migration at once.
>>>>
>>>> Being able to migrate not present pages (or pages mapped with incorrect
>>>> permissions, eg. COW) to the GPU requires doing either of the
>>>> following sequences:
>>>>
>>>> ...
>>>>
>>> Via which tree would it be best to upstream this?
>>>
>>>>  include/linux/hmm.h                    |  19 +-
>>>>  include/linux/migrate.h                |  26 +-
>>>>  lib/test_hmm.c                         | 101 ++-
>>>>  lib/test_hmm_uapi.h                    |  19 +-
>>>>  mm/Kconfig                             |   2 +
>>>>  mm/hmm.c                               | 821 +++++++++++++++++++++++--
>>>>  mm/migrate_device.c                    | 589 +++---------------
>>>>  tools/testing/selftests/mm/hmm-tests.c |  54 ++
>>>>  8 files changed, 1053 insertions(+), 578 deletions(-)
>>> Looks like mm.git.
>>>
>>> It might be more useful to add it to a DRM tree if there's ongoing
>>> development against this.  But please no upstreaming without good
>>> review!
>>>
>>> Anyway, this is a bit dated and Sashiko AI review wasn't able to apply
>>> the patches.  Nor was it able to apply v7 or v6.  So please refresh,
>>> retest, resend?
>> It is against Linus tree v7.0, base-commit: 028ef9c96e96197026887c0f092424679298aae8,
>> but applies and passes hmm selftests on mm trees as is.
>>
>> I plan to do v9 refresh and maybe minor updates in week or so.
>>
> It might be good to send a version which applies to drm-tip to
> intel-xe@xxxxxxxxxxxxxxxxxxxxx to trigger our CI too. I know tested an
> earlier rev and everything seemed to be working but another round of
> testing before merging is likely a good idea.
>
> Matt

Sure, will do that, thanks!

--Mika