Re: [RFC PATCH 0/9] mm: Memory providers for guest_memfd and iommufd

[David Woodhouse]

On Mon, 2026-10-12 at 09:58 +0000, Fred Griffoul wrote:
> 
> I plan to change the revoke anyway, because iommufd must not leave the
> device with a hole: it should replace mappings in place instead of
> unmapping and remapping. Would that fit your case? I suspect it depends
> on locking, for example whether you have to revoke while holding
> memory_lock.

I was keeping that hack *entirely* separate from the guest_memfd work.

That's a quirk on the IOAS in iommufd: "whenever you unmap, put *this*
page in its place instead". It doesn't belong anywhere near what we're
doing here, ideally.

I even talked to Jason about it about it at LPC, and he didn't hurt me.
If we implement a hitless¹ REPLACE operation then the scratch-page ends
up being a fairly trivial thing to redirect UNMAP to REPLACE (the
tricksy detail being that it uses the *same* scratch page for every
IOVA in the range).

¹ why do we call it that? Shouldn't it be 'missless'?

Attachment: smime.p7s
Description: S/MIME cryptographic signature