From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 4F97D19CC11 for ; Fri, 11 Jul 2025 20:19:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752265182; cv=none; b=owxCmjkesSgNGpFUNfY5aGBtcJBQyuAvp0riA/t/85GBI8bUZgoGlhvoU6CudzUgNEmbvZrMDz7zN0wsx3Q5t1/uEH1FpbW2In1BYwQZoCAi/pXGx5bswKZfUzkK3NW9DBF5wnadNkl+RWuKjS6PT6JvzzytPcXPSzLU9FaU+9k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752265182; c=relaxed/simple; bh=pnA59S//kLucI33SLPLNMt/VAXs6rqybvR8MkQ5JGmI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tcHFvUGUBJ3jlbVegwqVPfJAu7/Z1eO6ajDP1S1c2C22jTm6hrUqWofF9dbPARpzgumAN284tPLUnf8imhSK6WSUwxC5A7V9Q1356WJP+SAcsPdZF9ReT24EL9f/rUvI24GkZlU+VkLfNtkP90PzMIcgdYxon9Tu6cM5Kz8l+mg= 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=ucH3mN91; arc=none smtp.client-ip=209.85.216.73 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="ucH3mN91" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-3141f9ce4e2so3827577a91.1 for ; Fri, 11 Jul 2025 13:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752265181; x=1752869981; 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=2JPIsTcGu3PzRjBRBPaSZ6h7JDJNM68m0YAet5vg2Ms=; b=ucH3mN917I/pTJAHu+SGGpoeSy0RA4UuI56ekXWpKZJLdT5JQ03hlCu8Gba/1Oassd Azmkcc/CsoWhG+zcgy43HrtfIJ+HnYB2DB+kc9dYbexdyWtm4NGTGjcCoXJBdAxVQLgX YfsmgzG3BeyDQ24engxrFRFaQbBzA6Kz1ZTrllcM6MMaWTfUSDjRWckDSRzITdTjfVLl dFPzUSdO0tMtihOcWDJ/GaMkbCxBL/0Puy5y2AWZ+0SX7KOtUuusmmwbd+aK5piZj9o3 eAPhh1CXRn3OCLI5O/G4AF29Y2QncIeAMazRcTmnhhxBZhdr4iAleKln8vybaZI/5/R+ IVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752265181; x=1752869981; 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=2JPIsTcGu3PzRjBRBPaSZ6h7JDJNM68m0YAet5vg2Ms=; b=HgpwXHuDH9BD1YH8jVBtiDrpoQiu6tNYQoXCR4D9yTquzbItrsiJJCI+49ScmIrj9r gEnBBcnMmePrIIvy0x92vc4moFnjmGJXIkbvG9EV5EpVuGF1eAIrqX45n0l7/I3xNSDQ 5abZQD9c8pxb0lPA0q9ytTaPvMG+dw+NKavfHv2weJZ3jTW5rLQmFY1J10rpFagoJ7sb jHQ+kz7cggKsNmfRyCroOnL65khQovfInu3fXsgUSvPCMVII4I6AEzt3XG48lgkYtbqN bySXlK0BpAGtThoz3RK2unm0T+w1wcYkjekKEv5iHuAEiJe9tqQ1+rCdDnpaXGN9Itor RFxw== X-Forwarded-Encrypted: i=1; AJvYcCW05i7n1mcjbpswac43/hqbgWCqRB0wFHSEH3iqX8uJXffT0I30Teei4tyQu3XpdCY79uNl1QI+83rhPkY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5O6gByT/9HRFJ9wi5jhGtlaLt1eg+dLw0UbzjV5jA1o/ejBAb I8qms7thVhPtMfMPjePboumzDrLU/ZNkdf5zPEYjTSsfT7FYUyvMuZel52DpVtt2J5CJJFZir/a u8HzEkQ== X-Google-Smtp-Source: AGHT+IE6jEDwuGJPzaPjMy3zMp4wWJzRDJZe6xL+mp6zIDzjwiRhlPL5m4qyqH9zku8KZY/dtiqyIvbC7RA= X-Received: from pjbnd12.prod.google.com ([2002:a17:90b:4ccc:b0:311:c20d:676d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5105:b0:311:f2f6:44ff with SMTP id 98e67ed59e1d1-31c4f573304mr6033735a91.17.1752265180689; Fri, 11 Jul 2025 13:19:40 -0700 (PDT) Date: Fri, 11 Jul 2025 13:19:39 -0700 In-Reply-To: <20250711194952.ppzljx7sb6ouiwix@amd.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250703062641.3247-1-yan.y.zhao@intel.com> <20250709232103.zwmufocd3l7sqk7y@amd.com> <20250711151719.goee7eqti4xyhsqr@amd.com> <20250711163440.kwjebnzd7zeb4bxt@amd.com> <20250711194952.ppzljx7sb6ouiwix@amd.com> Message-ID: Subject: Re: [RFC PATCH] KVM: TDX: Decouple TDX init mem region from kvm_gmem_populate() From: Sean Christopherson To: Michael Roth Cc: Vishal Annapurve , Yan Zhao , pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, rick.p.edgecombe@intel.com, kai.huang@intel.com, adrian.hunter@intel.com, reinette.chatre@intel.com, xiaoyao.li@intel.com, tony.lindgren@intel.com, binbin.wu@linux.intel.com, dmatlack@google.com, isaku.yamahata@intel.com, ira.weiny@intel.com, david@redhat.com, ackerleytng@google.com, tabba@google.com, chao.p.peng@intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 11, 2025, Michael Roth wrote: > On Fri, Jul 11, 2025 at 11:38:10AM -0700, Vishal Annapurve wrote: > > On Fri, Jul 11, 2025 at 9:37=E2=80=AFAM Michael Roth wrote: > > > > > > > > > > > static long __kvm_gmem_populate(struct kvm *kvm, struct kvm_memory_= slot *slot, > > > > struct file *file, gfn_t gfn, void __= user *src, > > > > kvm_gmem_populate_cb post_populate, v= oid *opaque) > > > > { > > > > pgoff_t index =3D kvm_gmem_get_index(slot, gfn); > > > > struct page *src_page =3D NULL; > > > > bool is_prepared =3D false; > > > > struct folio *folio; > > > > int ret, max_order; > > > > kvm_pfn_t pfn; > > > > > > > > if (src) { > > > > ret =3D get_user_pages((unsigned long)src, 1, 0, &src= _page); > > > > if (ret < 0) > > > > return ret; > > > > if (ret !=3D 1) > > > > return -ENOMEM; > > > > } > > > > > > One tricky part here is that the uAPI currently expects the pages to > > > have the private attribute set prior to calling kvm_gmem_populate(), > > > which gets enforced below. > > > > > > For in-place conversion: the idea is that userspace will convert > > > private->shared to update in-place, then immediately convert back > > > shared->private; so that approach would remain compatible with above > > > behavior. But if we pass a 'src' parameter to kvm_gmem_populate(), > > > and do a GUP or copy_from_user() on it at any point, regardless if > > > it is is outside of filemap_invalidate_lock(), then > > > kvm_gmem_fault_shared() will return -EACCES. > >=20 > > I think that's a fine way to fail the initial memory population, this > > simply means userspace didn't pass the right source address. Why do we > > have to work around this error? Userspace should simply pass the > > source buffer that is accessible to the host or pass null to indicate > > that the target gfn already has the needed contents. > >=20 > > That is, userspace can still bring a separate source buffer even with > > in-place conversion available. Yeah. It might be superfluous to a certain extent, and it should be straig= ht up disallowed with PRESERVE, but I don't like the idea of taking a hard depend= ency on src being NULL. > I thought there was some agreement that mmap() be the 'blessed' > approach for initializing memory with in-place conversion to help > untangle some of these paths, so it made sense to enforce that in > kvm_gmem_populate() to make it 'official', but with Sean's suggested > rework I suppose we could support both approaches. Ya, my preference would be to not rely on subtly making two paths mutually exclusive in order to avoid deadlock, especially when there are ABI implica= tions. I'm not dead set against it, e.g. if for some reason we just absolutely nee= d to disallow a non-NULL src for the that case, but hopefully we can avoid that.