From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) (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 B2D3D322C6D for ; Fri, 8 May 2026 17:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262059; cv=none; b=cOochPnHg7JbKb9XqAEQVCy+0Z66s7RZawRcWM5f+6YvoFnrSncYqhfJv0ChPiEKaFdfhgz3xdCVAWw6J5XkdSejMh6JVaI4O1lvRI9YgQoNGXB6nnTFxi5Z3dkomUiDhuOVrGswVldTVb5qQIciilONxtssqza8XbcMBvEWnzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778262059; c=relaxed/simple; bh=zYlTeDh9G9IT4nS+zWqxNxxmSss2n8WYffkvXEx9Akw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CDDhpzVqDy/Csol29cWTEH3NKWbb+CLqor3Fas8i5WhtXuIMF3lCb904OvSFryq/jircYgExzM+f92mEf6k/sXDNJdiPmpGpcjJmuTFdo746sPhUn1TEMVV1/fgtlQrZJZwu6KC0o1stoJdiFwE+TOw9XxMu8rY4KW2HE7wexBo= 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=XdMv1nBY; arc=none smtp.client-ip=209.85.210.201 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="XdMv1nBY" Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-82f7bec24fdso1455552b3a.2 for ; Fri, 08 May 2026 10:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778262057; x=1778866857; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=uhr4BNU/ilo4uYM728zx4k0/Id92bF2OOCtFb+maHuk=; b=XdMv1nBYootU71I8CC7idKoT/q4s58ElcQcNrrSb8qo3Lm1TbCwJMn1iT0rT6UhqTi 00TqgaGCcfGiiuy5Iq14bMrIc7PAd8gDBc83/luLvScZobTZQlQ7GYukU0Z4Egi3z5Pm hsd5OTUodnJI/xDf+5O9A0yA322l+MmCQnnbdgEVb/0lurgQ1I4dYlZrf7TnjizCi8rC 5ffGcnqRAuV1I38RGHEU6GegmWCuql/dqgZA8ypovvpIC26qd2iaxhgKtZaPGlgJVHSy 2JJfk9ynavCkyodLfDGapmewkFVtD9eszEkVbKXy3jwo+HzgkWQzTTYB6B9ghlAXatwS S48A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778262057; x=1778866857; h=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=uhr4BNU/ilo4uYM728zx4k0/Id92bF2OOCtFb+maHuk=; b=PDlYNYfPqfJ0dchnOTswvR8BgdEBPbSSdK23CChuXxtslXlqaXWXMdYARjduI70W7A uGOelXYDzj7utdXQjSdpZY1T0i6J8y3oxz5yeW1b1tU2pNkN2N/o2SWJZj/ubQD3htnW b/in/f1hKubbPatEaE85Ik76oyh39SR423bCkhyPKHYy+Ows82iDwalegIJnvDCR7Xt6 YdESx1bkb2y7hQ6wDAQEYL4CEaBK3UnuDQCUlJH9JmP6btu6hWhvbb9VN74AuJ+FnBId ylPW4f1vYpFohIxgXYNFWCtpg2ngQZW9xKF0MCrHGzgfh+F0aL9H64hoNFXou9ob2phH vYQA== X-Forwarded-Encrypted: i=1; AFNElJ/snSFqoWfh7LYcsi6nxjpWUhah9i4PMy296Yp2gjgC1SmtWE5YzImGBR4uVJ4eR5WWs9AKJncnzuQfOuTJqGk=@vger.kernel.org X-Gm-Message-State: AOJu0Yxb9bkGr+ngaxZaoDUuYb9H8c3v8sjJu8kHCFx/QqNNaAa0az/h fieCEK/YLTWGMA01p59zVncY93/tmZuvXbFIzlDXcStct8h+tmsgIs+TYLeYHqMcWeUy73+H1ki FbOEokQ== X-Received: from pfjg10.prod.google.com ([2002:a05:6a00:b8a:b0:835:62a8:bbc]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:2998:b0:839:46b8:86be with SMTP id d2e1a72fcca58-83a5d686f07mr13095922b3a.33.1778262056375; Fri, 08 May 2026 10:40:56 -0700 (PDT) Date: Fri, 8 May 2026 10:40:55 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kselftest@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> <3blpenhpvysb2ig7efegedx4v3flppl5ftnz6vhpqlatfk3ycn@vmmhs7mvjieg> 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: 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 , Vishal Annapurve , 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="us-ascii" On Wed, Apr 29, 2026, Michael Roth wrote: > On Fri, Apr 24, 2026 at 12:08:45PM -0700, Ackerley Tng wrote: > > Michael Roth writes: > > > > Thank you for your patches! > > > > > > > > [...snip...] > > > > > >> > > >> I also did some minor updates (prefixed with a "[squash]" tag) to advertise > > >> the KVM_SET_MEMORY_ATTRIBUTES2_PRESERVED flag so it can be used by > > > > > > Though I'm not sure how we deal with it if SNP/TDX at some point become > > > capable of using the PRESERVED flag *after* populate... but maybe that's > > > too unlikely to worry about? If we wanted to address it though, we could > > > have both PRESERVED and PRESERVED_BEFORE_LAUNCH so they can be > > > enumerated separately from the start. > > > > > > > Not sure how likely it is, but if SNP and TDX can honor PRESERVE > > semantics after populate, I think we could implement support under a new > > flag like CIPHER. > > That works, but it still makes things *slightly* awkward due to special-casing > the PRESERVE semantics for 1 guest type vs. another. Summarizing this week's PUCK call[*]: Scrap PRESERVE and ZERO, and simply rely on vendor specific semantics. My desire to enforce PRESERVE and ZERO semantics and avoid relying on vendor specific behavior (i.e. on trusted firmware semantics) is a pipe dream. Unless KVM does a truly insane amount of per-gfn tracking, KVM can't know the state of memory for a given page, and so can't guarantee PRESERVE or ZERO will be honored. If userspace requests PRESERVE, just because it's _possible_ to preserve contents (e.g. during the pre-boot phase on TDX), doesn't mean the contents are _guaranteed_ to be preserved. If userspace doesn't actually ADD the memory to the guest's initial image, then the contents won't be preserved. Ditto for SNP. To guarantee PRESERVE, KVM would need to track per-gfn information to know if the memory was actually preserved. And enforcing PRESERVE would be all kinds of crazy; KVM would have to kill the VM or something? And that would still require userspace to be aware of vendor specific details. The same holds true for ZERO. On a private=>shared conversion, KVM can't guarantee the memory is zeroed by trusted firmware unless KVM tracks, per-gfn, whether or not the memory was actually fully assigned to the guest. E.g. if userspace does shared=>private and then private=>shared(ZERO), without the memory being faulted into the guest, then the TDX-Module won't have "seen" the page and so wont' have zeroed it on the private=>shared conversion. And trying to special case SNP's "validated CPUID" behavior, where memory can be preserved on private=>shared after a failed shared=>private, would also require tracking that the page was never actually converted to private. Note, regarding ZERO, someone (Mike? Ackerley?) pointed out that userspace typically doesn't rely on the kernel to zero memory, and so supporting ZERO for private=>shared isn't really all that valuable in the first place. [*] https://drive.google.com/file/d/1w0ifzh5PmNViJ1SKru9jK9x52MybXSNa/view?usp=drive_link