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

[Sean Christopherson]

On Fri, Jul 10, 2026, Lorenzo Stoakes wrote:
> On Fri, Jul 10, 2026 at 08:47:19AM -0700, Sean Christopherson wrote:
> > 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.
> 
> OK so it's a pinky promise that you won't write to it via GUP?

LOL, yep.

> It's still really crap to just allow drivers to ignore this, which is asking for
> abuse.

Yes, the KVM API in question is garbage, and for all intents and purposes it's
deprecated going forward, but unfortunately we're stuck with it.

> Is this something we could have a specific GUP helper for that is unexported? Or
> does a module have to use this?

Module, but we can limit to KVM modules via EXPORT_SYMBOL_FOR_KVM(), which also
discourages abuse by only providing the export if KVM is actually configured to
be built as a module.

> If not could we use some whitelisted approach or something to prevent arbitrary
> drivers from overriding this?
> 
> >
> > > By disallowing writable LONGTERM pins on FSes we broke one existing use case
> > > that was relying on that to work.
> 
> How long ago did I break this though? Why has it taken until now for this to be
> reported? :) commit 8ac268436e6d ("mm/gup: disallow FOLL_LONGTERM GUP-nonfast
> writing to file-backed mappings") is from May 2023 :)

The break didn't come from your changes, it came from commit 7e066cb9b71a ("KVM:
SEV: Use long-term pin when registering encrypted memory regions").  I suggested
falling back to a non-longterm pin, but David didn't like that idea :-)

https://lore.kernel.org/all/akVAnGuiuJttE5-6@xxxxxxxxxx

> Is it vendors moving slow to update distros? Does speak to the usefulness of
> testing mainline asap in any case.
> 
> I maybe missing details about the actual motivating issue here sorry!
> 
> Thanks, Lorenzo