All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Pankaj Gupta <pankaj.gupta@amd.com>,
	pbonzini@redhat.com, tglx@kernel.org, mingo@redhat.com,
	dave.hansen@linux.intel.com, 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
Subject: Re: [PATCH] KVM: SEV: drop FOLL_LONGTERM for encrypted region registration
Date: Wed, 1 Jul 2026 18:39:04 +0200	[thread overview]
Message-ID: <d9f98e2f-d2c6-447a-b3b1-17f07d1fac3f@kernel.org> (raw)
In-Reply-To: <akVAnGuiuJttE5-6@google.com>

On 7/1/26 18:30, Sean Christopherson wrote:
> On Wed, Jul 01, 2026, David Hildenbrand (Arm) wrote:
>> On 7/1/26 16:45, Pankaj Gupta wrote:
>>> 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?
> 
> Ya.
> 
>> If it is a longterm pin, it must use FOLL_LONGTERM. :/
> 
> Heh, well, KVM showed that that's not entirely true for many years :-)

What exactly do you mean? KVM MMUs sync through memory notifiers and doesn't
need this.

It's only our "interesting" CoCo code :)

> 
> Assuming we can't solve this some other way, and that there are "real" use cases
> that were broken by adding FOLL_LONGTERM, maybe this as a hack-a-fix?

Well, it's not a driver's decision to make. :P

But, can we actually whitelist virtio-pmem in GUP code somehow?

I mean, it does not suffer from the documented writeback issue, that we wanted
to protect from. We similarly allow shmem and hugetlb there.


-- 
Cheers,

David

  reply	other threads:[~2026-07-01 16:39 UTC|newest]

Thread overview: 11+ 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) [this message]
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)

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=d9f98e2f-d2c6-447a-b3b1-17f07d1fac3f@kernel.org \
    --to=david@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pankaj.gupta@amd.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.