From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.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 B19D413C9C4 for ; Wed, 8 Apr 2026 00:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775608440; cv=none; b=NiMwH8NeHWDZa5kRqzfYBdV/0Z8oMOMbhq/tm2J1XXfhXiqo0/SmpHgIRm2+KrImOZ89CPtfyFAYwg7VIaQ+Y5Xkf/unWk0n4wwPDmLtMUFhbT4z55eg2svZn9Dg3jaNdb+o3HRlgUE4vRGcwG79aWCaEqK9ffzBtLuHL4RBfA4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775608440; c=relaxed/simple; bh=J8lObzK2Uu3gpSZOZmzqAZdfXNnRkzBYDt7uUjpmnZM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=uqdmOxaJ00JeANb6gVjTucYOcGqbmGvrM3+KDf/iEB8zvZXXsWy552pI4Pz46F9PVq46+QXVNnDjZG037Psg7DestHRYxR3fVcStUK9bas+jJZG9pyhdHgOPuAyammUPcpv/J13VPTt7hxR6GRpEjw325VDvFZoCWRKQV/Yo1dw= 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=cu84yI5u; arc=none smtp.client-ip=209.85.215.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="cu84yI5u" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-c76b15a3ccfso2936767a12.3 for ; Tue, 07 Apr 2026 17:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775608439; x=1776213239; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=aDLo9VPnGDiQNlFQzI1xTSPzRXpWtFJbtAFYR59HS10=; b=cu84yI5uGATzgiiPJMHlB2b0nhG2G745ru0KXCVeLcnRULppZ2atz/7LGlUVA1T6ge Xlz8DVcTJ5y1RcNb9A820K3AcKvpEoEpMr6pGTSvoPJv6s945P+GvNM6MWt7woSitMXp T8tCCYunhRtgjd/46Vx4uYK58GWIV2G23Mh2Bau9hZqX8eC6sSL7+2+5TVGhFLtb9/PV MdNvmlUUvIRZ8lHEmztn8tuURuQdJCRarztpoMq2KGvXcg4aPaSzgycxcE6CE4o2ZY3F FzSpn81daFM0nkUBc53ApcCjOE79XVBGcSzWJNegoU1LVQH+lfOWjLq+szrVicNjpxlx I//A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775608439; x=1776213239; h=content-transfer-encoding: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; bh=aDLo9VPnGDiQNlFQzI1xTSPzRXpWtFJbtAFYR59HS10=; b=I+ejA1c/QN1TgpAANG1lDumABqCcv/IN2of2Ef2ZAyt3ZFw81L5IlXMHwIXUYg1Wxq NuhbBwHmtnzRTeBYMxjz/X4SRNpkt0djB0zihTAcoKmkMo4RpV1Q8j1iPUI64tkB4gfi X2CZ5QFU97jjcy85fD+J1TVDGJY8o2YxTHdyMui7LsHJGxZKam5SNaA1bWMBzMcm5iFY KraRrzNSnSYw7tn9tOkEG0rrhJ2u9ytyCmZAxWiwMtz4pZggKMow9cVI3DDCNeeKbENJ 5fdN2Bx+B3fmHKY0MMQMDp7cfmBQbBHX27MVqTuHUu1tI5FRrkKSW7qNEXbr8KgurCPC jHdw== X-Forwarded-Encrypted: i=1; AJvYcCXQLZe+54TzxaqmePqQ5NyDBx+YLAKXR6zqkZWYSOzvvdDTECjN98urN+9KmL8H4sqvsUa8cy32WBg=@vger.kernel.org X-Gm-Message-State: AOJu0YzuZEHfdHT7huuQyHyJ4Mkhxy4GUuyzrRuzWvjM0kuHH5Vi5TN9 bugVAanCYmCEfkzvPiqDz6XMfR2VvRP2EPXw9AcCy6p6syyF4sXvWiYRZnGb5wQLfvuyP6WzWqS ApW0iEA== X-Received: from pfbmt5.prod.google.com ([2002:a05:6a00:6e65:b0:82c:6e7c:ac61]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:3011:b0:801:eee2:45b6 with SMTP id d2e1a72fcca58-82d0dac592amr17920681b3a.24.1775608438815; Tue, 07 Apr 2026 17:33:58 -0700 (PDT) Date: Tue, 7 Apr 2026 17:33:57 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260326-gmem-inplace-conversion-v4-0-e202fe950ffd@google.com> <20260326-gmem-inplace-conversion-v4-10-e202fe950ffd@google.com> <2r4mmfiuisw26qymahnbh2oxqkkrywqev477kc4rlkcyx7tels@c7ple7kdgpo3> Message-ID: Subject: Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2 From: Sean Christopherson To: Michael Roth Cc: Vishal Annapurve , Ackerley Tng , aik@amd.com, andrew.jones@linux.dev, binbin.wu@linux.intel.com, brauner@kernel.org, chao.p.peng@linux.intel.com, david@kernel.org, ira.weiny@intel.com, jmattson@google.com, jthoughton@google.com, oupton@kernel.org, pankaj.gupta@amd.com, qperret@google.com, rick.p.edgecombe@intel.com, rientjes@google.com, shivankg@amd.com, steven.price@arm.com, tabba@google.com, willy@infradead.org, wyihan@google.com, yan.y.zhao@intel.com, forkloop@google.com, pratyush@kernel.org, suzuki.poulose@arm.com, aneesh.kumar@kernel.org, Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jonathan Corbet , Shuah Khan , Shuah Khan , Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jason Gunthorpe , Vlastimil Babka , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 07, 2026, Michael Roth wrote: > On Tue, Apr 07, 2026 at 02:50:58PM -0700, Vishal Annapurve wrote: > > On Tue, Apr 7, 2026 at 2:09=E2=80=AFPM Michael Roth wrote: > > > > > > > TLDR: > > > > > > > > + Think of populate ioctls not as KVM touching memory, but platform > > > > handling population. > > > > + KVM code (kvm_gmem_populate) still doesn't touch memory contents > > > > + post_populate is platform-specific code that handles loading into > > > > private destination memory just to support legacy non-in-place > > > > conversion. > > > > + Don't complicate populate ioctls by doing conversion just to supp= ort > > > > legacy use-cases where platform-specific code has to do copying o= n > > > > the host. > > > > > > That's a good point: these are only considerations in the context of > > > actually copying from src->dst, but with in-place conversion the > > > primary/more-performant approach will be for userspace to initial > > > directly. I.e. if we enforced that, then gmem could right ascertain t= hat > > > it isn't even writing to private pages via these hooks and any > > > manipulation of that memory is purely on the part of the trusted enti= ty > > > handling initial encryption/etc. > > > > > > I understand that we decided to keep the option of allowing separate > > > src/dst even with in-place conversion, but it doesn't seem worthwhile= if > > > that necessarily means we need to glue population+conversion together= in > > > 1 clumsy interface that needs to handle partial return/error response= s to > > > userspace (or potentially get stuck forever in the conversion path). > >=20 > > I think ARM needs userspace to specify separate source and destination > > memory ranges for initial population as ARM doesn't support in-place > > memory encryption. [1] > >=20 > > [1] https://lore.kernel.org/kvm/20260318155413.793430-25-steven.price@a= rm.com/ > >=20 > > > > > > So I agree with Ackerley's proposal (which I guess is the same as wha= t's > > > in this series). > > > > > > However, 1 other alternative would be to do what was suggested on the > > > call, but require userspace to subsequently handle the shared->privat= e > > > conversion. I think that would be workable too. > >=20 > > IIUC, Converting memory ranges to private after it essentially is > > treated as private by the KVM CC backend will expose the > > implementation to the same risk of userspace being able to access > > private memory and compromise host safety which guest_memfd was > > invented to address. >=20 > Doh, fair point. Doing conversion as part of the populate call would allo= w > us to use the filemap write-lock to avoid userspace being able to fault > in private (as tracked by trusted entity) pages before they are > transitioned to private (as tracked by KVM), so it's safer than having > userspace drive it. >=20 > But obviously I still think Ackerley's original proposal has more > upsides than the alternatives mentioned so far. I'm a bit lost. What exactly is/was Ackerley's original proposal? If the = answer is "convert pages from shared=3D>private when populating via in-place conve= rsion", then I agree, because AFAICT, that's the only sane option.