All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gupta, Pankaj" <pankaj.gupta@amd.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
	seanjc@google.com, pbonzini@redhat.com, tglx@kernel.org,
	mingo@redhat.com, dave.hansen@linux.intel.com
Cc: bp@alien8.de, x86@kernel.org, thomas.lendacky@amd.com,
	hpa@zytor.com, yangge1116@126.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	"Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
Subject: Re: [PATCH] KVM: SEV: drop FOLL_LONGTERM for encrypted region registration
Date: Wed, 8 Jul 2026 18:35:33 +0200	[thread overview]
Message-ID: <1d0cf7b6-fe94-4a5e-bdbc-e75a371a41f7@amd.com> (raw)
In-Reply-To: <27ebe8f0-78b6-402a-a2e7-4e807251d20a@kernel.org>

Hi David, Sean,

Thank you for the discussion!

>> Yes. For file based mapping we don't allow long term pinning.
>>
>> If we take into account the fragmentation concerns for MIGRATE_CMA and
>> ZONE_MOVABLE allocations
>>
>> solvable with FOLL_LONGTERM, I can think of two options(tested) to allow file
>> based mappings as well:
>>
>> 1. Fallback on FOLL_WRITE when FOLL_LONGTERM fails as suggested by Sean.
> That is just not acceptable, as it breaks random other stuff (MIGRATE_CMA, as
> one example) besides the file-pinning problems that Lorenzo added.
>
> If we're going to hack something in, then that we bypass the file writeback check.
> Not that we don't use FOLL_LONGTERM.
>
> I'd hate to use a GUP flag to indicate "this is a legacy hack", but it clearly isolates the
> issue (needs a better name obviously):
>
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index ae9bca4eda5ca..e2c531f914d44 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1912,6 +1912,9 @@ enum {
>           */
>          FOLL_HONOR_NUMA_FAULT = 1 << 12,
>   
> +       /* TODO */
> +       FOLL_LONGTERM = 1 << 13,
> +
>          /* See also internal only FOLL flags in mm/internal.h */
>   };
>   
> diff --git a/mm/gup.c b/mm/gup.c
> index 0692119b79043..1fa0aa0cdc99d 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1186,8 +1186,8 @@ static bool writable_file_mapping_allowed(struct vm_area_struct *vma,
>           * If we aren't pinning then no problematic write can occur. A long term
>           * pin is the most egregious case so this is the case we disallow.
>           */
> -       if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM)) !=
> -           (FOLL_PIN | FOLL_LONGTERM))
> +       if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_LONGTERM_HACK)) !=
> +           (FOLL_PIN | FOLL_LONGTERM | FOLL_LONGTERM_HACK))
>                  return true;
>   
>          /*
> @@ -2746,7 +2746,7 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>           * If we aren't pinning then no problematic write can occur. A long term
>           * pin is the most egregious case so this is the one we disallow.
>           */
> -       if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) ==
> +       if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE | FOLL_LONGTERM_HACK)) ==
>              (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
>                  reject_file_backed = true;
>   
> @@ -3180,7 +3180,7 @@ static int gup_fast_fallback(unsigned long start, unsigned long nr_pages,
>          int locked = 0;
>          int ret;
>   
> -       if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
> +       if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM | FOLL_LONGTERM_HACK |
>                                         FOLL_FORCE | FOLL_PIN | FOLL_GET |
>                                         FOLL_FAST_ONLY | FOLL_NOFAULT |
>                                         FOLL_PCI_P2PDMA | FOLL_HONOR_NUMA_FAULT)))
>
David,

Yes, the above approach works with few changes [2]. If it looks okay 
will send a v2 .

Best regards,

Pankaj

[2]

> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index b18c2b2e7d2c..f9af801788b0 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1911,6 +1911,14 @@ enum {
>          */
>         FOLL_HONOR_NUMA_FAULT = 1 << 12,
>
> +       /*
> +        * Long-term pin without kernel GUP writes.  For callers that pin
> +        * writable file-backed mappings only to prevent migration.  
> Must be
> +        * used with FOLL_PIN and FOLL_LONGTERM.  Bypasses the writable
> +        * file-backed long-term pin restriction in gup.c.
> +        */
> +       FOLL_PIN_NO_GUP_WRITE = 1 << 13,
> +
>         /* See also internal only FOLL flags in mm/internal.h */
>  };
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 0692119b7904..a83d100f7950 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1186,6 +1186,10 @@ static bool 
> writable_file_mapping_allowed(struct vm_area_struct *vma,
>          * If we aren't pinning then no problematic write can occur. A 
> long term
>          * pin is the most egregious case so this is the case we disallow.
>          */
> +       if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM | 
> FOLL_PIN_NO_GUP_WRITE)) ==
> +           (FOLL_PIN | FOLL_LONGTERM | FOLL_PIN_NO_GUP_WRITE))
> +               return true;
> +
>         if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM)) !=
>             (FOLL_PIN | FOLL_LONGTERM))
>                 return true;
> @@ -2530,6 +2534,11 @@ static bool is_valid_gup_args(struct page 
> **pages, int *locked,
>         if (WARN_ON_ONCE(!(gup_flags & FOLL_PIN) && (gup_flags & 
> FOLL_LONGTERM)))
>                 return false;
>
> +       if (WARN_ON_ONCE((gup_flags & FOLL_PIN_NO_GUP_WRITE) &&
> +                        (gup_flags & (FOLL_PIN | FOLL_LONGTERM)) !=
> +                        (FOLL_PIN | FOLL_LONGTERM)))
> +               return false;
> +
>         /* Pages input must be given if using GET/PIN */
>         if (WARN_ON_ONCE((gup_flags & (FOLL_GET | FOLL_PIN)) && !pages))
>                 return false;
> @@ -2747,7 +2756,8 @@ static bool gup_fast_folio_allowed(struct folio 
> *folio, unsigned int flags)
>          * pin is the most egregious case so this is the one we disallow.
>          */
>
> +       if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM | 
> FOLL_PIN_NO_GUP_WRITE)) ==
> +           (FOLL_PIN | FOLL_LONGTERM | FOLL_PIN_NO_GUP_WRITE))
> +               return true;
> +
>         if ((gup_flags & (FOLL_PIN | FOLL_LONGTERM)) !=
>             (FOLL_PIN | FOLL_LONGTERM))
>                 return true;
> @@ -2530,6 +2534,11 @@ static bool is_valid_gup_args(struct page 
> **pages, int *locked,
>         if (WARN_ON_ONCE(!(gup_flags & FOLL_PIN) && (gup_flags & 
> FOLL_LONGTERM)))
>                 return false;
>
> +       if (WARN_ON_ONCE((gup_flags & FOLL_PIN_NO_GUP_WRITE) &&
> +                        (gup_flags & (FOLL_PIN | FOLL_LONGTERM)) !=
> +                        (FOLL_PIN | FOLL_LONGTERM)))
> +               return false;
> +
>         /* Pages input must be given if using GET/PIN */
>         if (WARN_ON_ONCE((gup_flags & (FOLL_GET | FOLL_PIN)) && !pages))
>                 return false;
> @@ -2747,7 +2756,8 @@ static bool gup_fast_folio_allowed(struct folio 
> *folio, unsigned int flags)
>          * pin is the most egregious case so this is the one we disallow.
>          */
>         if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) ==
> -           (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
> +           (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE) &&
> +           !(flags & FOLL_PIN_NO_GUP_WRITE))
>                 reject_file_backed = true;
>
>         /* We hold a folio reference, so we can safely access folio 
> fields. */
> @@ -3180,7 +3190,7 @@ static int gup_fast_fallback(unsigned long 
> start, unsigned long nr_pages,
>         int locked = 0;
>         int ret;
>
> -       if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM |
> +       if (WARN_ON_ONCE(gup_flags & ~(FOLL_WRITE | FOLL_LONGTERM | 
> FOLL_PIN_NO_GUP_WRITE |
>                                        FOLL_FORCE | FOLL_PIN | FOLL_GET |
>                                        FOLL_FAST_ONLY | FOLL_NOFAULT |
>                                        FOLL_PCI_P2PDMA | 
> FOLL_HONOR_NUMA_FAULT)))
>

  reply	other threads:[~2026-07-08 16:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01 14:45 [PATCH] KVM: SEV: drop FOLL_LONGTERM for encrypted region registration Pankaj Gupta
2026-07-01 14:58 ` sashiko-bot
2026-07-01 16:25 ` David Hildenbrand (Arm)
2026-07-01 16:30   ` Sean Christopherson
2026-07-01 16:39     ` David Hildenbrand (Arm)
2026-07-01 16:56       ` Sean Christopherson
2026-07-06 12:03   ` Gupta, Pankaj
2026-07-07 10:04     ` David Hildenbrand (Arm)
2026-07-07 13:45       ` Gupta, Pankaj
2026-07-07 13:59         ` Sean Christopherson
2026-07-07 14:58         ` David Hildenbrand (Arm)
2026-07-08 16:35           ` Gupta, Pankaj [this message]
2026-07-09 14:28           ` Lorenzo Stoakes
2026-07-09 15:19             ` Gupta, Pankaj
2026-07-09 15:44               ` Lorenzo Stoakes
2026-07-10 12:57                 ` David Hildenbrand (Arm)
2026-07-10 13:05                   ` Lorenzo Stoakes
2026-07-10 15:37                     ` David Hildenbrand (Arm)
2026-07-10 15:47                       ` Sean Christopherson
2026-07-10 16:13                         ` Lorenzo Stoakes
2026-07-10 16:24                           ` Sean Christopherson
2026-07-10 16:38                             ` David Hildenbrand (Arm)
2026-07-10 16:58                               ` Lorenzo Stoakes
2026-07-10 13:06                   ` Gupta, Pankaj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d0cf7b6-fe94-4a5e-bdbc-e75a371a41f7@amd.com \
    --to=pankaj.gupta@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    --cc=yangge1116@126.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.