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 898B3C282EC for ; Fri, 14 Mar 2025 20:04:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F528280002; Fri, 14 Mar 2025 16:04:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5805A280001; Fri, 14 Mar 2025 16:04:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F7EB280002; Fri, 14 Mar 2025 16:04:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 237FF280001 for ; Fri, 14 Mar 2025 16:04:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2B7D2AA235 for ; Fri, 14 Mar 2025 20:04:31 +0000 (UTC) X-FDA: 83221233942.07.17AE6AE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id C251B18001D for ; Fri, 14 Mar 2025 20:04:28 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BETgXGyc; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741982669; a=rsa-sha256; cv=none; b=WvGCr/SjAAYp0OqHXwheSvkbZubnlsTBHNkDfJWYu8IcAWpn7P0xeyTY90C9BMX3BJRsqH dfEJ1FJYhPGcN0TK+/lMx4mDNP0YyAS56i2fHz/9M6zN8dMbzTW8E1p7WLG0bhhBLB9xN4 3ua/6p7bKcyScCjZ4x/fOcuPGY5RZ6A= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BETgXGyc; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.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=1741982669; 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=SqRyL6MA+QupMYvedIjsb0gClHlzTIPhGP8UWlhlKow=; b=VkLJFF4akFBSgFNCsAj7AnMqjKCzigDAeK/rCTjGqQncqwivoZF+APqIgMF/lkFEePqIWp K1kYthyia1rZ5dBepiz3pHxdgyJmfsnNDyqxrc8lFQ0fLE0Q5v/GhFionvAzLXnzG6KHxr IezoyYPFbQ3LSF+VgG3yFVsV8dY6taI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741982668; 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=SqRyL6MA+QupMYvedIjsb0gClHlzTIPhGP8UWlhlKow=; b=BETgXGycdZWuO9oR9Y2bVNgAni4rUCIqlAn4IX0qRfDMhn0hV1K5hm+TWfLhCzUakF+eT6 wa0PoYTG4fp8nijnY2oU8hGcuE6TNPPgkHD4Z5iiHc0wG/6tq22k+dkYRcx2qKZQCDEgnk 2zen00gAKeTKeNlwtx82Hv/aAtYbRck= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-659-Q5fW6jJDNWOgDknfJtu9jw-1; Fri, 14 Mar 2025 16:04:24 -0400 X-MC-Unique: Q5fW6jJDNWOgDknfJtu9jw-1 X-Mimecast-MFC-AGG-ID: Q5fW6jJDNWOgDknfJtu9jw_1741982664 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6e8ea277063so60490846d6.1 for ; Fri, 14 Mar 2025 13:04:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741982664; x=1742587464; 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=SqRyL6MA+QupMYvedIjsb0gClHlzTIPhGP8UWlhlKow=; b=goPZcD6gHcMu3LZtYGuic+0x0/sn611zdGPQoErFkMPJLd0z5ECv+HalCBlhSpcSSj y8FqwwwiZMQbvl6TA0j59Voqcs4h3zhWebKpmXyf2rlVhSYJAGPtJc6WIiID7s8uNotp Y1H+ON6gPHTDyKVQqKe4WwH7d2o2B/+tO8h5QW7j/cNbSS10y9z6+b4YUHxhnIs1t0+u dwRhWAhofPfrziqPxYL+7ST35u/8TgcCPIIJOPj3p8sT9ZYW0UodZjj91eacBMJCequs YX2Ll2jDDrOOS+98cmVtFGdAeabAss7UwXgZtt9SpAKT08jE1EfRj2NrIOVwZmYVN3WC D2sQ== X-Forwarded-Encrypted: i=1; AJvYcCULvJOBQZTkqbET5nNSRtt93apWDIg9AenFtM2EKChUo2JQyajFGCPyASpUJTvBcZGSrx/NFQv+yQ==@kvack.org X-Gm-Message-State: AOJu0YysYIFzjJNLVdxjTWoRLMDcgygx3Wy9tUGJTHfc9H+9J1UoeaNJ dYa33wYVpIbozXhmCCIU9llIRtddBi3yIWZdAy9JbpWuUyFRObqIwXVCWN+5a53TqKZDjbaVz+w FNFkUOLsRQ1Tz1LE0QR0xX2URRZGXY8L7g/9amFKY4x0Udlwu X-Gm-Gg: ASbGncs7DDvpdJzffI0E0h4YLbA02EoIUfXEQt1IEJ/fAAJhk/lqgM/1/VSjsaaKzPJ xPF3IxheSEwun4b0WSgUeJzxIdxVxs7MuPm2P9SaaL4yIAxzXN4hm5ejThpo7aruVy5W8o53n28 iAfvrBQaZwhzdKRpH8bipcfNMvJ+jGyf+c5htFcNJsPHH1Blbv1OercWdGqpCm7WneVQAKhKyUy AyvuxhCrWnYNP8RHABTQQWkRQDgcw/8QC20eIG8M3jXKR89I6YXd6UvDAqeq8QK1c/oVXcwd9Kb aoTUgjE= X-Received: by 2002:ad4:5cca:0:b0:6e8:f65a:67bd with SMTP id 6a1803df08f44-6eaeaa1c6e7mr54402486d6.11.1741982663657; Fri, 14 Mar 2025 13:04:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHdrnxZkVhHJCu+0L4gTXfr+cGtUYoXrRv2lUDPgB5Dtd3VDIpsWxWp29AXtnPsgwf8cd2wQQ== X-Received: by 2002:ad4:5cca:0:b0:6e8:f65a:67bd with SMTP id 6a1803df08f44-6eaeaa1c6e7mr54402066d6.11.1741982663335; Fri, 14 Mar 2025 13:04:23 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6eade209335sm27689416d6.22.2025.03.14.13.04.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Mar 2025 13:04:21 -0700 (PDT) Date: Fri, 14 Mar 2025 16:04:17 -0400 From: Peter Xu To: Nikita Kalyazin Cc: James Houghton , akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lorenzo.stoakes@oracle.com, david@redhat.com, ryan.roberts@arm.com, quic_eberman@quicinc.com, graf@amazon.de, jgowans@amazon.com, roypat@amazon.co.uk, derekmn@amazon.com, nsaenz@amazon.es, xmarcalx@amazon.com Subject: Re: [RFC PATCH 0/5] KVM: guest_memfd: support for uffd missing Message-ID: References: <9e7536cc-211d-40ca-b458-66d3d8b94b4d@amazon.com> <7c304c72-1f9c-4a5a-910b-02d0f1514b01@amazon.com> <69dc324f-99fb-44ec-8501-086fe7af9d0d@amazon.com> <507e6ad7-2e28-4199-948a-4001e0d6f421@amazon.com> <24528be7-8f7a-4928-8bca-5869cf14eace@amazon.com> MIME-Version: 1.0 In-Reply-To: <24528be7-8f7a-4928-8bca-5869cf14eace@amazon.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: g7ClnlOOxMEDkM9s75p2aFcD37fZFODzVSQm5R-APkw_1741982664 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: C251B18001D X-Stat-Signature: 6rakfzc1oypmb5t3fggus64gnmy3pcb4 X-Rspamd-Server: rspam06 X-HE-Tag: 1741982668-498993 X-HE-Meta: U2FsdGVkX1/ejwzVx2F7uBTTJmplyp9o7PmxbgUy/EZw/DwxtAG7Ef1/JUc3PSzocNFSd+leRPyDa5/dFeC9kLjWi9Rc4xg7rgFkR1uF530XDdhlUhanOMjaoRea6lpZi9HtPY2Q/pqw2NUDXHcElmIuOlfXetL/kuIegioYlm4obYS83tW28sMF4UN6tYmjH791jBIpAy82yOsufSv5fB+3XiLp8scIhL+DQ4Z6gQzhu900VKtrX9pqNqfmF8zWfLqfUDixN7izOfGhuobprL5nnV1xb42Xn/owpT1xkBs5rlhoiciEWf6dlUz38TdreWdEbJJCXr/tqThL3diH0GxLqs8SVxJPVgRKBWqyeLDebpxPgsMpWcnDIf3gF16bai+ExpqRueYE0PskJB18D195xKzWdxsUl7BMM6BUEqDgWub/NThEe0fRaWxXuCgv1yExTepc6Bbgj1wG/FNMEWq1OP3FyjVYcY9IFZfkVjiW8+yewuXVtD1GJHUBs/y10xdAOMEpJl+yaBl+ruBSEwE/nQlo4c7EdzO983SJely9EkvcYHjfbBFjG+zt91qIzYwXJ78VWWKRYOuQ8Xe72XiXUF0d7LpT69iTgVeR/YfCTtLqAdPvjciShBIL2hufpMCWh5TxpyLrrfWhUK6Oz1JrOjuPceD8YCMTJjuNmFyKAxIRJufX23edx1gBmMVTAK4rwzOmQiQLeXl4KMPTU/0AymH0njqOgSdbJm/vrF8gbNmYq2PGUmX+0kdeg3t9Y9FCJpANX/jZzeXOnrkNilw9RKS6/Rk1rMZBzWb9McWEwPQqowRlRh5C6DOIeLUeGvFg8tWPuVI5greU55HyNGvf7kLvRp36MedZc5ljSwIimSBTAl9L4Bs8GLTivJ5iS0Evyn9VadnIaMwKJrB3BmM0gbC7BgWJzsnV5wpp8wM2xaPs0YWrpyjxz0bO/YkiWCcm2gw7qWHsrnpsdN/ 0P685YLh 8/lxtllSdPU1MwfxW/MNu1ZiI5YeQwDBWNYkhOxnDREwW26EGX6fereluP3+QTLio+mNu4eywB7UR2I0wYZnEoDJ9OyHOmccrBOY9CvmRfBmhlR7/Qy/nojtuUQly8orisqN9IsxOH3Y3pP+vTTvGpTlYBZa55QyHHyC75YiebZUYIGVPxowzBcPnoKpADtAqNcpoG8H+8S22tFet9EfslWSTdrIFmbwCDSonJsqdvgY2Kszdi68wqE9zy4eV5gLoU9+Z9hQyn34M3FEuWGaRtoXO2r40KIQuRiS3Eeh833F7WLWyqDPl7Zyje2cbQsfvEGwi/fwiBFi4XEv7R4s9YdAEzeDjpRIhAB/I/BUHYGJ+mLs2b3BCTPX3G8/O+9Q6xztr48l2EzifAPOtevCityf7CQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Fri, Mar 14, 2025 at 05:12:35PM +0000, Nikita Kalyazin wrote: > Anyway, it looks like the solution we discussed allows to choose between > memcpy-only and memcpy/write-combined userspace implementations. I'm going > to work on the next version of the series that would include MINOR trap and > avoiding KVM dependency in mm via calling vm_ops->fault() in > UFFDIO_CONTINUE. I'll attach some more context, not directly relevant to this series, but just FYI. One thing I am not yet sure is whether ultimately we still need to register userfaultfd with another fd using offset ranges. The problem is whether there will be userfaultfd trapping demand on the pure private CoCo use case later. The only thing I'm not sure is if all guest-memfd use cases allow mmap(). If true, then maybe we can stick with the current UFFDIO_REGISTER on VA ranges. In all cases, I think you can proceed with whatever you plan to do to add initial guest-memfd userfaultfd supports, as long as acceptable from KVM list. The other thing is, what you're looking for indeed looks very close to what we may need. We want to have purely shared guest-memfd working just like vanilla memfd_create(), not only for 4K but for huge pages. We also want GUP working, so it can replace the old hugetlbfs use case. I had a feeling that all the directions of guest-memfd recently happening on the list will ultimately need huge pages. It would be the same for you maybe, but only that your use case does not allow any permanant mapping that is visible to the kernel. Probably that's why GUP is forbidden but kmap isn't in your write()s; please bare with me if I made things wrong, I don't understand your use case well. Just in case helpful, I have some PoC branches ready allowing 1G pages to be mapped to userspace. https://github.com/xzpeter/linux/commits/peter-gmem-v0.2/ The work is based on Ackerley's 1G series, which contains most of the folio management part (but I fixed quite a few bugs in my tree; I believe Ackerley should have them fixed in his to-be-posted too). I also have a QEMU branch ready that can boot with it (I didn't yet test more things). https://github.com/xzpeter/qemu/commits/peter-gmem-v0.2/ For example, besides guest-memfd alone, we definitely also need guest-memfd being trappable by userfaultfd, as what you are trying to do here, one way or another. Thanks, -- Peter Xu