From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EBE9438037 for ; Fri, 10 Jul 2026 15:47:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783698444; cv=none; b=k/dnpVavrx0v0lmbDuAUD1dM3aUMsQ2/8oecMcKKWNKmhr2kEJyjYh2HSkpDs2e7uNEhsXq4gRytUqJQOLDpOj2f6ZuqE15d8Xc70l3JJMrZrFmmvvfgqCETuCvBpNOAmGvCZPAz1tAZl4e5jY68hdP31b++B/ZGC+Pg0GQCVlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783698444; c=relaxed/simple; bh=ePCbnM94woPFBEAhYEbp+ydZtO5vCzsjSDw668DqpUw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=R1P9u68WPdwSuMzE0KN6S2fVUKBDd9R2Y+W/tLQRA4OtgrAnYtLyWIyQeepCyOQqUUYbyfp2iB4VcKzgSzq7xL5krei/CMAaDIdzohE4EldQryFlNg5Ahy/lO2Vji6/iTvacWPp3x+r3NR5W/9VdjYgTs+ihDCyRHPYtLH3LOUU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=b8yN4/jV; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="b8yN4/jV" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-8482fd61e83so2010963b3a.1 for ; Fri, 10 Jul 2026 08:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783698440; x=1784303240; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=a2o8RM3DU4+oABpSO+Km7GLJNJZxTuit0tDVpvpEDVU=; b=b8yN4/jV8HG3QOyiLb4aQsENJTNwsWLPk7u0juNOzGwIYAutypT65rXKcTqcoJuBkv zKt822gTLXc7Gp9eJLyd3zndeff7GtEBpGmnIIPqKhd1gXBY2rxsjYNn8uE76ANnDX6R XuE4BDIgUWON8onqZ5XLvD2qP67XytbixbTHYvMKDLBTw4lgNVYO4Of+Th4qSnp8ggIW Xt2S2gtUcGOyYULOQDv/iiOj6A0lTCYNuj+FtPPN7ueylOt6HDJBGT2mCdA3wImNLKBF GYaBmGqTuho7xzWYcBjKzWjfKmV5L4ByWdjqmITSxu8yX31U7Nxd5P5M7x0knroEnDLm wY0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783698440; x=1784303240; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=a2o8RM3DU4+oABpSO+Km7GLJNJZxTuit0tDVpvpEDVU=; b=b92sYoy/hzgDylwnxCafVIux4yqUf8FWqKc7iH0Wl17+KvBySNNs4mCW7OU5gRKT+M rKxZIlzwR25qha0eaKG2t5o7I6jN/U9NzETimGjzzb2/MB1myEZdiJE8vW65W/oetben qUHD9p9haGc/k4ofqHvj8fS1GuFimUHU/00vMXNNLvMTcw/JFvEjwrGnJktvEy62GtTU 5V8tO/V+NeoZJ7fNsBJAWgKR0qgSEkM+Lf79hVqgSNjkI3ePR4MKGR/lqB7c3hrlMR42 Svgf8sVd4yDMq9erfYuSeuoBskhCg24zpcmFYoSVBi4MZ8DckxTskvWmeKJpB+DASziF Ja1A== X-Forwarded-Encrypted: i=1; AHgh+RrydKqlZ/yNnyqSsk2O2JiPltvEU8b6nBSQjkIIA+WZJLpGnsqIH2yyyQ0g5spMVnsc3Eg39JkYIBGcmkM=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5BFMn0+M0MNPSQG4FkgwyAvfnNFiGD9Rf3QlKcQL0KC49nUFl oWoOOCr1wFLk2nenzdEhjcGQcfIJ7c/N33H9TkA2w5hyt6YiSXhqwMtyoDxvgPmUC9TQuB4hqx4 M9CFddQ== X-Received: from pfnn21.prod.google.com ([2002:a05:6a00:2b95:b0:848:3d5d:8106]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:aa7:9067:0:b0:846:1b9:cb63 with SMTP id d2e1a72fcca58-8484356de46mr12723650b3a.62.1783698440079; Fri, 10 Jul 2026 08:47:20 -0700 (PDT) Date: Fri, 10 Jul 2026 08:47:19 -0700 In-Reply-To: <62ccb0f7-a619-41b8-944e-11ae2d0ce70c@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <46f19bd8-0d43-4b0e-a8ab-0ef9d3b8bd1a@kernel.org> <2bd89e95-9c15-4a3a-916d-0d71a92d8b02@amd.com> <27ebe8f0-78b6-402a-a2e7-4e807251d20a@kernel.org> <58c4326d-b10d-42dc-af5d-3a5ff16c7e3e@amd.com> <62ccb0f7-a619-41b8-944e-11ae2d0ce70c@kernel.org> Message-ID: Subject: Re: [PATCH] KVM: SEV: drop FOLL_LONGTERM for encrypted region registration From: Sean Christopherson To: "David Hildenbrand (Arm)" Cc: Lorenzo Stoakes , Pankaj Gupta , 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 Content-Type: text/plain; charset="us-ascii" 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.