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 04C1E438036 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-8486389f71cso1345554b3a.3 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=HJLF8UVWmYdwWK9MaWKUfg/g0xbYLf2Kr0rlDyIJsiD1fKvAOHokyELWFn3J4auluq o6wSEPKktbsQwuxrXwakX2wOVIRhzg98zUP6djPXfjCQfYet4fkxKCGKXvMlR+tfc96v 7Z7xYQ5zgHRi4NBrpdmdoPjdrV97e9WrjROJw2yjn0XRRqgfSc72OIayzBDiDDu3ckVx XxsxbUGpZpncPpTJkt4fqFDbbRxQdQ9Kgf8wYyxVdqLYg9gZOCbwI/PSNKtw2MPzrVG/ q5ZW2SqfnVkOsMm7DumOwOkMQQdUZcc8t38lBR5wQdjstcceMfbqM3B8pik99QOP5Ku1 RcIw== X-Forwarded-Encrypted: i=1; AHgh+RrLlaT+qQFuCPkYyGsNraZUXwVKykB8IqULHpdJl+Vn7SX47etHMNRXrzjIpOMLLR2MzEQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyVM27qijKcxOmc+FR59zphm8bDLZEThQ91mjLSMkkhh7MlBv/k LTQlNQH4SE3pl/7DgIG1TOwgzu0SFX9Y9mJyU+fspNhZOqlu2RZV/XV/l9wdT9gWkjWO5jlT1fx EqD/EaQ== 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: kvm@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.