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

[Sean Christopherson <seanjc@google.com>]

On Fri, Jul 10, 2026, David Hildenbrand (Arm) wrote:
> On 7/10/26 15:05, Lorenzo Stoakes wrote:
> > On Fri, Jul 10, 2026 at 02:57:55PM +0200, David Hildenbrand (Arm) wrote:
> >> On 7/9/26 17:44, Lorenzo Stoakes wrote:
> >>>
> >>> OK as long as that's made clear in the patch, commit message, comments etc. :)
> >>>
> >>>
> >>> Ack yeah I assumed it was a quick proof of concept and just overlooked it :P
> >>>
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> hmm but we have FOLL_LONGTERM as an adjunct to FOLL_PIN (doesn't make sense
> >>> without - any checks that exist for that btw should be extended to this noew
> >>> flag).
> >>>
> >>> Also don't we want to encode the legacy aspect here?
> >>>
> >>> Maybe FOLL_LONGTERM_LEGACY_READONLY? Naming is hard :)
> >>
> >> I'm confused about the _READONLY, well. and the FOLL_PIN_NO_GUP_WRITE.
> >>
> >> We want to longterm write-pin.
> >>
> >> @Pankaj, how come you would call this "FOLL_PIN_NO_GUP_WRITE" -- why "no GUP
> >> write" ?
> >>
> >> I agree that someting like FOLL_LONGTERM_LEGACY_* is the right thing to do, but
> >> I don't see where this is "no write" or "readonly" ?
> > 
> > I based it on Gupta saying 'without kernel GUP writes, and therefore not
> > impacting dirty tracking'
> > 
> > I mean I think we definitely need some clarification here yes :)
> > 
> > Not really got the bandwidth to dig deep into GUP again :P
> 
> I think the KVM gueest *will* write to these pages.

Yes, the guest will write these pages, but through KVM's normal mechanism for
mapping memory into guests.  The host will NOT write this memory via the GUP
pins though.  KVM needs to pin the pages because the memory is (well, technically
may be) encrypted (by the CPU) with a key that is only used/accessible when the
guest is active, and the encryption is salted with the system physical address of
the page.  E.g. attempting to migrate the page would corrupt guest memory due to
copying ciphertext that would decrypt different at the new PA.

> By disallowing writable LONGTERM pins on FSes we broke one existing use case
> that was relying on that to work.