From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 AA9F222B5AC for ; Tue, 5 Aug 2025 19:59:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754423966; cv=none; b=Lk9tk8zIfTLFHqgPcwLfLW0Oix99m+/5/3HtyXXenNaSIzEOuKBH7oH96ABDvgm6AzGmawa/GZAStf4WMlo9suBFf7iDATHY3lfa6ZU2vaE8VYiSK1pQxY9CwKFGZZuPGuoGty96ly7d+C80AswUv8Mr8iBQeuU6am7aQvOb1+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754423966; c=relaxed/simple; bh=pXhxchSRRgtxWJx8jVY2QY92qQA379bq+J7HbDgvShU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=MGki4hJIJl9NY8AUkuufPvv9HDR2XBAkqUiDAnM4jCjAv/knrfzPpGZA8nduMO6o+6ctLVfviMPxTL4dFZNZGTleuxMXlDlanO5yFsHk737f7u/il3cCPkXpIknSYJD9Fn2gmLRnjRRM9oQhpSDsTjTarkFpwbiQucqqfQfJ66Q= 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=SPVwXk9r; arc=none smtp.client-ip=209.85.216.74 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="SPVwXk9r" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-31f729bf733so8594711a91.1 for ; Tue, 05 Aug 2025 12:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1754423964; x=1755028764; 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=w3Yvf2JfDXGKcx67v9ooLLvg0JCE6s5eg0KrtzPSvSI=; b=SPVwXk9rlSJWnmlbW2bmHhgn1zxdmjolLq9toYnkL9Odbdz6PFCyss55pgh+ACNQ4H I777PmMXBUXYAWa/nQdSh0o34s7qZpy4+v5oKhHw+01mf0ecNLEcbowx9QW2DuwqwKQW TEI0U7nzF5nfKSHPH2SN5G6ICc79DUxWGRmAikcrrdcRG45gGv5EjabaMt7DJEEdU8iT 2VRSE/rL0gb6v7O/oHCDC6BAmWQZs2jPCxZXNlp7NVTII1usZPtiHletraIbxFUZBGDs 9035KSjs6KHpkuPHWZ8i1g2n/YY0gjLEiapWzwVa5l/xxAHyti25J730jxaEvL07CcDo s9lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754423964; x=1755028764; 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=w3Yvf2JfDXGKcx67v9ooLLvg0JCE6s5eg0KrtzPSvSI=; b=R5XtBNUCi49wTrkgPsKyAoSn9r5uMxR0f5O3C8nqOzQ8jHoLEEmSaTXR27y+BleLVX 6QeZeYadY3Rdgrg9x80AmVQmyQlJG6dk+enAq66YfpqWqXl7IAeTzm6KLFCpUsEWQ5vg ppOyZ2tlmeoQGTSZVZzxvYKsDDkUEXBHzm0gqoCabJpcKV1b7pfuEkTAQTBqvqJkbU+3 8+V7ZD0ODbSMY2+I33SJn1xDiALbEHpzyNJeKRF8aV9//hPevCEFakGYDTPHgqCkiX6C u+xcIymjxHZ66O6WJea3IqTt6wxbImnrMYEyoeuVFN/Yro3/ean6cv5LEhI6xfioBHK8 gIPA== X-Forwarded-Encrypted: i=1; AJvYcCWooRDxFx3vbSEmUT/N4/bgbY0qsaifRC+wNNZvR7yUJ9WASo2EaAGkAxxXsJ4+nUIZI+/Z/XPIs3+5CvE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2rFBcDC0f/Q8Q+XPzluMwu+Jh1gkeRhGkyyShEZnhv5KAkpQu tKehT4QvkFNUV1sXu/78WEqrU0Y8qnNGo7MRXE6d0iAY29tfz9xMrfZIpdYLuIiT4HyZJ5q5saJ PM86h1g== X-Google-Smtp-Source: AGHT+IEuI8KiE77OJVjXZOrcYjc8/vveaA71MtGaUeonbU64/fh8UEXUNZAQbuVlyWgScx/PDrxoAQPbFoQ= X-Received: from pjbpx16.prod.google.com ([2002:a17:90b:2710:b0:2e0:915d:d594]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:5584:b0:312:51a9:5d44 with SMTP id 98e67ed59e1d1-32166c15c64mr147232a91.5.1754423963903; Tue, 05 Aug 2025 12:59:23 -0700 (PDT) Date: Tue, 5 Aug 2025 12:59:22 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <6888f7e4129b9_ec573294fa@iweiny-mobl.notmuch> Message-ID: Subject: Re: [RFC PATCH] KVM: TDX: Decouple TDX init mem region from kvm_gmem_populate() From: Sean Christopherson To: Vishal Annapurve Cc: Ira Weiny , Yan Zhao , Michael Roth , 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, 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 Mon, Aug 04, 2025, Vishal Annapurve wrote: > On Mon, Aug 4, 2025 at 5:22=E2=80=AFPM Sean Christopherson wrote: > > : 4) For SNP, if src !=3D null, make the target pfn to be shared, copy > > : contents and then make the target pfn back to private. > > > > Copying from userspace under spinlock (rwlock) is illegal, as accessing= userspace > > memory might_fault() and thus might_sleep(). >=20 > I would think that a combination of get_user_pages() and > kmap_local_pfn() will prevent this situation of might_fault(). Yes, but if SNP is using get_user_pages(), then it looks an awful lot like = the TDX flow, at which point isn't that an argument for keeping populate()? > Memory population in my opinion is best solved either by users asserting > ownership of the memory and writing to it directly or by using guest_memf= d > (to be) exposed APIs to populate memory ranges given a source buffer. IMO > kvm_gmem_populate() is doing something different than both of these optio= ns. In a perfect world, yes, guest_memfd would provide a clean, well-defined AP= I without needing a complicated dance between vendor code and guest_memfd. B= ut, sadly, the world of CoCo is anything but perfect. It's not KVM's fault tha= t every vendor came up with a different CoCo architecture. I.e. we can't "fi= x" the underlying issue of SNP and TDX having significantly different ways for initializing private memory. What we can do is shift as much code to common KVM as possible, e.g. to min= imize maintenance costs, reduce boilerplate and/or copy+paste code, provide a con= sistent ABI, etc. Those things always need to be balanced against overall complexi= ty, but IMO providing a vendor callback doesn't add anywhere near enough complexity= to justify open coding the same concept in every vendor implementation.