Re: [PATCH v10 09/15] KVM: guest_memfd: Add flag to remove from direct map

David Hildenbrand (Arm)
2026-03-10T00:00:47Z

On 3/6/26 15:49, Nikita Kalyazin wrote:
>
>
> On 06/03/2026 14:22, David Hildenbrand (Arm) wrote:
>> [...]
>>
>>>
>>> Dave pointed earlier that the failures were possible [1].  Do you think
>>> we can document it better?
>>
>> I'm fine with checking that somewhere (to catch any future problems).
>>
>> Why not do the WARN_ON_ONCE() in folio_restore_direct_map()?
>>
>> Then, carefully document (in the new kerneldoc for
>> folio_restore_direct_map() etc) that folio_restore_direct_map() is only
>> allowed after a prior successful folio_zap_direct_map(), and add a
>> helpful comment above the WARN_ON_ONCE() in folio_restore_direct_map()
>> that we don't expect errors etc.
>
> My only concern about that is the assumptions we make in KVM may not
> apply to the general case and the WARN_ON_ONCE may become too
> restrictive compared to proper error handling in some (rare) cases.  For
> example, is it possible for the folio to migrate in between?

Not without migration support. But then, migration would have to make
sure that the destination folio has the direct map removed. So I
wouldn't worry about that.

Once you return an error from folio_restore_direct_map(), you better
document when/why it happens and how the caller should handle it.

There is nothing existing callers could really do, so it's an
implementation detail of the
folio_zap_direct_map()/folio_restore_direct_map() functions to make sure
it keeps working.

If it ever fails, we'll have to figure out how to keep the interface
working.

You can document any restrictions regarding when
folio_zap_direct_map()/folio_restore_direct_map() is allowed to be used
in the kerneldoc.

--
Cheers,

David