Re: [PATCH] KVM: SEV: drop FOLL_LONGTERM for encrypted region registration

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/6/26 14:03, Gupta, Pankaj wrote:
> Hi David,
> 
>>> commit 7e066cb9b71a ("KVM: SEV: Use long-term pin when registering encrypted
>>> memory regions")
>>> added FOLL_LONGTERM to sev_mem_enc_register_region() so anonymous guest RAM is
>>> migrated out of MIGRATE_CMA/ZONE_MOVABLE before a long term pin. This breaks
>>> virtio-pmem which has file backed (MAP_SHARED) host mapping where GUP rejects
>>> FOLL_WRITE | FOLL_LONGTERM since:
>>>
>>> commit 8ac268436e6d ("mm/gup: disallow FOLL_LONGTERM GUP-nonfast writing to
>>> file-backed mappings")
>>> commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
>>> file-backed mappings").
>>>
>>> Drop FOLL_LONGTERM when registering encrypted memory regions and restore
>>> the previous behavior.
>> But that breaks the original issue of breaking ZONE_MOVABLE/CMA?
>>
>> If it is a longterm pin, it must use FOLL_LONGTERM. :/
>>
>> I assume we fail in check_vma_flags()
>>
>>     if ((gup_flags & FOLL_LONGTERM) && vma_is_fsdax(vma))
>>         return -EOPNOTSUPP;
> 
> Yes, it fails in this path but for file backed mapping, vma_is_fsdax() returns
> false because
> 
> vma_is_dax() returns false:

Ah, okay, so fsdax is not involved and we really only fail because of the
writable_file_mapping_allowed() check.

I was for a second thinking in terms of nested virt :)

> 
>>
>> IIRC, fsdax cannot tolerate unbounded pins. Is that the case we are running into?
> 
> Host side backend is regular file backed memory (no fsdax).

Okay, so we'll end up mapping an ordinary file into VM memory, and expose that
to the VM as part of virtio-pmem device.

That also means that vfio etc. won't be able to longterm-pin such device memory.
So this is not a problem isolated to SEV.

Forbidding to longterm pin is actually the right thing to do if the filesystem
relies on writenotify, as spelled out by Lorenzo's commit:

"
    Writing to file-backed mappings which require folio dirty tracking using
    GUP is a fundamentally broken operation, as kernel write access to GUP
    mappings do not adhere to the semantics expected by a file system.

    A GUP caller uses the direct mapping to access the folio, which does not
    cause write notify to trigger, nor does it enforce that the caller marks
    the folio dirty.

    The problem arises when, after an initial write to the folio, writeback
    results in the folio being cleaned and then the caller, via the GUP
    interface, writes to the folio again.
"

Hmmm

-- 
Cheers,

David