From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 752D2D3C527 for ; Thu, 17 Oct 2024 17:05:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0C0F6B0082; Thu, 17 Oct 2024 13:05:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABCBA6B0083; Thu, 17 Oct 2024 13:05:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95CB06B0085; Thu, 17 Oct 2024 13:05:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 781EA6B0082 for ; Thu, 17 Oct 2024 13:05:58 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 84B95801F0 for ; Thu, 17 Oct 2024 17:05:48 +0000 (UTC) X-FDA: 82683721302.23.75AB97A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 09FB2160003 for ; Thu, 17 Oct 2024 17:05:48 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PfzY6Kqi; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729184707; a=rsa-sha256; cv=none; b=ssN+yslFJYRXflOtHBUubGHyBwvPdu1dHA4bPoTjjjNNkX6356iWfu5Fbo2ZnqezFsOayf yBkLgowCErjhy0SXZfkPq5eYJ+Dz+/KvjIyed/Rn/pi6QTKLYDgUVnfRcNa65ron8xO9RN bcJXd8d3RtPeMniCWpz/z4V59xeSzbw= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PfzY6Kqi; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729184707; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pTxdalYG31XpePFBi14kwyLsxFtz4ngJLPKLlOmswew=; b=abEGFPM+nzpIP0sTw6/qKAJNYpO2ZYWmdGMRN/hKlDzHawMAdw4ra//GhyUvlrIhIqKXI4 8OohK1NFq5iMp+JICigsH3LE0qz2BJC69vX/e6tlooKrOh66kuO7Hp5bFRL0fsHqeUuRE4 h9DMsnntsMjPUiOr/DcPnuoamGwUoFQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729184755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pTxdalYG31XpePFBi14kwyLsxFtz4ngJLPKLlOmswew=; b=PfzY6KqiKPiFyvF0qNrKWt8hVKUDJ55D7Q6OWmFLJlMBomZ98jjZ9YNUjPc1nsjHIintwE OHcH8y9u0dDlErAH67lSn6+5IqniKcRJBw5hcdCGNMkvKBQhhVgoEU300829ZsBiOPMleg FfmCMLRLTBcoYLuwjBJ34pfvBGSdovg= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-258-NUjANN-nOjSdJRSOGakZ3w-1; Thu, 17 Oct 2024 13:05:53 -0400 X-MC-Unique: NUjANN-nOjSdJRSOGakZ3w-1 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-7b13ff957cbso146637585a.0 for ; Thu, 17 Oct 2024 10:05:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729184753; x=1729789553; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pTxdalYG31XpePFBi14kwyLsxFtz4ngJLPKLlOmswew=; b=kfxDVOOPCS4DmQe4pc5jT0llS7MqCP2RYdcC2aKH6nWQPDaI0bHHnAbQSalsCyHTRv XQH8YuU02hP4waVDFOIdFlH4ZmPrPEoop0lYclsNrw46zjOrPRA5lFROZkH0PlJitd9g swGHjKZuuAiHu2156DFNlr87Le2fIbYPFKa8U/VZk3mwbchHwGu2HFUYM1PD1E6Onqcu Kxfljw5zXqZdDz2DLUi0pRQ5R8x57k6Cmwi+Mji/IqWeapqN3Uh0n8Cryo9YtLY5mSmw WlP3BnvJD2rFWPWZf9I6VtQKSjZ/2wbIbDHQCCx5fFjmCoOawm5U3kGqF1lMyKdtYk/q HKpA== X-Forwarded-Encrypted: i=1; AJvYcCVUKveeJbk2+2GEezQU2UvzwrQWhACwT+nJUVnVTszd9SUUamBCgQ02gSHYC6ucyAvhK1xVq6DoUg==@kvack.org X-Gm-Message-State: AOJu0Yynow3hVLK9WA2xf2ecbJT2+Qjd483w6p8L9qwvX/9mY5zaLK/M sWSK6/ZxR+Qcb+ivu7KIIpC2+bOkoHIfuueuUavgM/cLjl0bAPCUVmmu4n7bGPD4df1EVeGtWUo Y6wcc4UwBg7MWU03ZV+foiGjTAPAqg2/K3RdUr0yzmk1pG/u9 X-Received: by 2002:a05:620a:372c:b0:7a9:aba6:d037 with SMTP id af79cd13be357-7b1417b3191mr1094416585a.13.1729184753078; Thu, 17 Oct 2024 10:05:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHD0En3wQDJBS0nydKh7vHrLHOJlIadS3w4LKE69c5NsvIujdsOvlVIWDnzPR18WON37rexWg== X-Received: by 2002:a05:620a:372c:b0:7a9:aba6:d037 with SMTP id af79cd13be357-7b1417b3191mr1094408885a.13.1729184752627; Thu, 17 Oct 2024 10:05:52 -0700 (PDT) Received: from x1n (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b136170dd7sm308639185a.53.2024.10.17.10.05.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2024 10:05:51 -0700 (PDT) Date: Thu, 17 Oct 2024 13:05:34 -0400 From: Peter Xu To: Jason Gunthorpe Cc: David Hildenbrand , Ackerley Tng , tabba@google.com, quic_eberman@quicinc.com, roypat@amazon.co.uk, rientjes@google.com, fvdl@google.com, jthoughton@google.com, seanjc@google.com, pbonzini@redhat.com, zhiquan1.li@intel.com, fan.du@intel.com, jun.miao@intel.com, isaku.yamahata@intel.com, muchun.song@linux.dev, erdemaktas@google.com, vannapurve@google.com, qperret@google.com, jhubbard@nvidia.com, willy@infradead.org, shuah@kernel.org, brauner@kernel.org, bfoster@redhat.com, kent.overstreet@linux.dev, pvorel@suse.cz, rppt@kernel.org, richard.weiyang@gmail.com, anup@brainfault.org, haibo1.xu@intel.com, ajones@ventanamicro.com, vkuznets@redhat.com, maciej.wieczor-retman@intel.com, pgonda@google.com, oliver.upton@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH 26/39] KVM: guest_memfd: Track faultability within a struct kvm_gmem_private Message-ID: References: <1d243dde-2ddf-4875-890d-e6bb47931e40@redhat.com> <20241016225157.GQ3559746@nvidia.com> <20241016235424.GU3559746@nvidia.com> <20241017164713.GF3559746@nvidia.com> MIME-Version: 1.0 In-Reply-To: <20241017164713.GF3559746@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 09FB2160003 X-Rspamd-Server: rspam01 X-Stat-Signature: motm65c13sjncywsk75ztc4db534x37o X-HE-Tag: 1729184748-930437 X-HE-Meta: U2FsdGVkX19gF2hrJ4KEWCXENMG+P82QhG6z9pPi6MHUl9ZIYvVQkYfWioY44m9PxnIMPPLlS+XguynZrbQP3GMqYHS+GeVW1Rm3R0QZ+KrGYQoqnrm1mUPG+0huErMelQxA4viXtjFtk6aMDz+eYk+i8lLnIO5LK4MLiAKQS7aU6+pnfkA2UCXYO2K0FrIAQ2PLAwuQa4uuJstfYHXakC4XZRwHlBjGW9bi27FMw/5H+lLH9jmPkjwCO8BoIG895V3AnGdAwm4MoINd1s577DEZmGFLv3eIx6ZYXWGyb9OaWhpDBundh2QP2UPokU1OhQLZ+XaXIFxQZ3w4MuiW5tBFdVeEJlzLUyktua77LrYQc2NbHZd5ID4PgyPrCk4vjcPuN5xwbv9DGHS3mZFtHfz2enPHBJZgAa7KA6kkPmMi2xfkTW2xvSWAfNBKuaffjwr4bVNnWIecNriyJd+iPh83FQQ4lrwV58sfcmAF3DvHxUTks4v7CInMSVr0u5A9VmeMQpgtM10bH4AnePgtYdtva4PtSuUmhlRcfBRBW4JltoBeFOe56Cyb+S4NSjbiLREVk+WDNY2S9vCSwb86HlHyH9D5i8oqkMJn/Jj5O03ItdrzO0JlVAfa0LZRfHm7oKiNEblItaGG3eViSJbpy3RxUcOXQHwxpxwCHn0Of1xiOv3cpUfMbyJ78Q6Nhs1uItfITDHwE15S75CziGA+/oR5ZoBn8hnLf3CQlSW3qM3xiZ0eqMmGXRplTsNYXud7iQsz7EfUXke2pXEdb0bBq9VUmUz7dvfqp4qU49n6RQHa0KpneQPic1rITXUoXUm/IVsy1H6M+qx9pWVHXOPg9HZB5uJ2gGFlLEoLsq6cxXIN1FIFgZmBOm4zhPAISSG3uefFmycCZBxQz0LJ9JAR62Ljc6wbsFgMHHCSm6DWSOaplhheGApUyy5KyqefwDka9pn5O27H48sj2fYx2kf m5Vc41Y0 R1Xv5jYkqGz6Jsdf0JH0j2xjQHEkUVVvrd0j7iTJ7KR+ykXqOOvQGxGaQur7GkZa19ri/IN3RHu1GIFBo3hAmyJMgBKjuDJtZdL3Z6Tr1jwCJ714Om3QbFKU5t1T8LrJfugmxQhlKsjQdnIrIP4qitxX7z99hnBNh/nUlzpjaWpgp6MummKK1dXaeTajya9AFC5IOW2N/2j/nU1eq9hQZ+laoIDt5pzgPgiv9yQ48xDsapStDII0L+SWlhShYU86uQrgB5ljBJmiX+svHY0Y8r2J5NsAyLPKHlBNByDcIR+FB3RaAZk1QyZQfKGVSTDNQ2c/ofm1H640NxC3Cb0OxlA0sZ2GmhoaXuC/6wh5N6CJL0Ee91ARSCI6fp/z8ZN3OfY8hhPYTbqRLfPSRwz9UzSg2aOSlCyXBmYqqBTRXuyBAaN3E3oCdE+32UEI1yEaBhscXYZAo/gZx4497STvKWdUN7R9wulQYPa84pys/NR2SSKI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.002610, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote: > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote: > > > My question was more torwards whether gmemfd could still expose the > > possibility to be used in VA forms to other modules that may not support > > fd+offsets yet. > > I keep hearing they don't want to support page pinning on a guestmemfd > mapping, so VA based paths could not work. Do you remember the reasoning of it? Is it because CoCo still needs to have a bounded time window to convert from shared back to private? If so, maybe that's a non-issue for non-CoCo, where the VM object / gmemfd object (when created) can have a flag marking that it's always shared and can never be converted to private for any page within. So how would VFIO's DMA work even with iommufd if pages cannot be pinned? Is some form of bounce buffering required, then? It sounds like if so there'll be a lot of use cases that won't work with current infrastructure.. > > > I think as long as we can provide gmemfd VMAs like what this series > > provides, it sounds possible to reuse the old VA interfaces before the CoCo > > interfaces are ready, so that people can already start leveraging gmemfd > > backing pages. > > And you definitely can't get the private pages out of the VA interface > because all the VMA PTEs of private pages are non-present by definition. It's the same as "not present" if the fault() gets a SIGBUS always for private pages, IIUC. My prior references to "VA ranges" are mostly only for shared / faultable pages. And they'll get zapped too when requested to be converted from shared -> private, aka, always not present for private. > > Hence, you must use the FD for a lot of use cases here. Thanks, -- Peter Xu