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 9661DC71157 for ; Wed, 18 Jun 2025 09:26:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E9696B0088; Wed, 18 Jun 2025 05:26:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C0F16B0089; Wed, 18 Jun 2025 05:26:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B03B6B008A; Wed, 18 Jun 2025 05:26:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EC3086B0088 for ; Wed, 18 Jun 2025 05:26:03 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A30FC1A0F1C for ; Wed, 18 Jun 2025 09:26:03 +0000 (UTC) X-FDA: 83567989806.05.59BF9CF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 3B3D74000C for ; Wed, 18 Jun 2025 09:26:01 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=D9zCNcAW; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750238761; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=noez7PDMjGNfyqAC2iiFATetkxxnOVVDqKKI/+ShM2Q=; b=OhwOaJuipgHGS5hp7OTUTjYhk2t1aNC3V4Nkb7RWr7g0j0EiyxERwpBTif0zKFPMVfZ9hk CGFUw/vnP4F5GOfgdsb6d8ktuU24tP3aekRbye8wfEVI+TuE99EAUvAgNGAfU2Ik1F+IzN pTvO/Lgj1Zs/jbarJwW5Xhg/dH+OHoc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=D9zCNcAW; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750238761; a=rsa-sha256; cv=none; b=UeUqBOwn94nj+YL8fc9nNG0Z970fkCXqmpQMRuz2dYJNoaSFNfe8TJXw61isP5MIlYZlqs eKPaG2Vgq0WpV3ZSITtnOvhxsE2VUr2iR3ahBT1gzvub/j6QXrydIXIZhqlPyPmRMCeddh dqjw1roBTegSLTjO8uarUthBdGJQdOI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750238760; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=noez7PDMjGNfyqAC2iiFATetkxxnOVVDqKKI/+ShM2Q=; b=D9zCNcAW664TkAOTpod4HHyc8ZGuA220UTzMjv65frHFZzH9oIhGlXuz9ltMVG7T6uyliC JeuS9RVPUYdARqGKjnLJPHYhhxbmZhJKf/rFnjj3766xA53EGu/f1GdsJXVuAK2Nh6xV9y jdDNVybdeBBqiZGz3acxgOAxO2IAubI= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-75-ZCnTYf-3NO26tvRu6Paeug-1; Wed, 18 Jun 2025 05:25:58 -0400 X-MC-Unique: ZCnTYf-3NO26tvRu6Paeug-1 X-Mimecast-MFC-AGG-ID: ZCnTYf-3NO26tvRu6Paeug_1750238758 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43e9b0fd00cso3047075e9.0 for ; Wed, 18 Jun 2025 02:25:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750238758; x=1750843558; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=noez7PDMjGNfyqAC2iiFATetkxxnOVVDqKKI/+ShM2Q=; b=Ph0hCODJRjFOHuOCyZItIhgspbfn0tpqSCpiLW1FYYPTFzwnkaIYMoHlXmEGMFk4iC Q2j7n/mN3S9wXRpODY9R9R0zC+RbE+ewDddxoux8P9YDyLLZrYaxVYUlAAsrggINFRCn rz3rVGSwjMQ0RH7PvDT/CdpCpPpfFLN6fgaFEhh+G8Et9kMPWuFp2eso4oNw3JTalPGB 87tEHgrn2Xgwe/YBSiB5zdVRMWe+WqIU2gJV/ypFTeNHSxYnDBJw2Se9KnPSIrwbhyay uh8FombJSJGH/wdqudZwqJqzOQ6jy7bkaG90XsI0pcJFpop3sdhntK8UJeDnN/kWpleK j+WQ== X-Forwarded-Encrypted: i=1; AJvYcCVTB34KH/WWmEJkmEbeSduvs367YC0zzdL6kM5afE14m7JUrbze4Vyj0EXdBxEZPwg6+bSj1G6I0g==@kvack.org X-Gm-Message-State: AOJu0YyS/p8bVuQS6V2/2ZkFsxQRELjZQpYxb9zdvgUA3eWlSBIeRlOF X9FxAD8tYYtHGRw5hZ2A5kluwxZ7TjYgqyzBX2fnGn4Pbnrp+KrAw89LaZZ4oe+0/OkvfFVqbsf E0kyWCAtn31TSYcPuI7yOoC5pcn2Scn+fAwW1tXgmWwnOCOK0Hf/B X-Gm-Gg: ASbGncu5c++HE6rLtl54FXtau3HKIBRiWKTuJTkN5dvsW42XlMmjzRLT+rMvMS7FnCt rvV9VXzejTZMaTSWT0piwXVGFvdomyUpJe4x0Yb2wJNBPDNu9jQ/3Dqb7B41dq+ZwAie6Qb4sTz IdsdnuQnskE99ioEiWf4Q7vONv6H/YJF7bo+Inqrgl5AdVUfkXS8Sbc3oWkh3056fdIkiX1gpqA VMsIB9bAnR5egbQ2eweGullnDMdcv+rg0uTxscmEGyi/Nt4VpastG+XMXD/nifdLGLttsGwqqPE 0tiRrGp1ejYOGtS2wIElvZqDFtS8xjib20Px2mEIdEm9yNfkSTKiJEB12qi1vSQWePXqbe1sIOd +U6IuT5ipjQciJfmUkw+2y+7mGv1SwrJnXyS8iYO7Nk/pkXc= X-Received: by 2002:a05:600c:c109:b0:453:84a:e8d6 with SMTP id 5b1f17b1804b1-4535996524amr12310135e9.1.1750238757664; Wed, 18 Jun 2025 02:25:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGuGwoj8/gwtmr/WyWhYG1KWkxADFjLP/JXwSfXswYNhIZMwDVtmJ6h2OCLLp788xTNZ9fKTQ== X-Received: by 2002:a05:600c:c109:b0:453:84a:e8d6 with SMTP id 5b1f17b1804b1-4535996524amr12309365e9.1.1750238756701; Wed, 18 Jun 2025 02:25:56 -0700 (PDT) Received: from ?IPV6:2003:d8:2f2d:2400:4052:3b5:fff9:4ed0? (p200300d82f2d2400405203b5fff94ed0.dip0.t-ipconnect.de. [2003:d8:2f2d:2400:4052:3b5:fff9:4ed0]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e256630sm206510575e9.29.2025.06.18.02.25.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jun 2025 02:25:55 -0700 (PDT) Message-ID: <9f252a62-9232-4048-ac10-0c6cdf2154fe@redhat.com> Date: Wed, 18 Jun 2025 11:25:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages To: Sean Christopherson , Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com References: <20250611133330.1514028-1-tabba@google.com> <20250611133330.1514028-9-tabba@google.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: A9R8EYeXvYGhhtziywnjfFuCt8D-G7p3Qd8-yUlbxCQ_1750238758 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3B3D74000C X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: dm15khd4pxoppdsg89hg4peye49s4d7u X-HE-Tag: 1750238761-239837 X-HE-Meta: U2FsdGVkX18GKnUSRw6PtSC6SsFag/HdPH6JJwNoOZs/VRrsxGsaLCvdUvktzrRMWj8ePK9bbXVwLq1ogOFmE6ygKsRFEsLM//JDFTCnNQ4AlQvTsn4w5b7X3DHr47DAVNJxOUrbwlNQatpQFG4tdv29G99J/sycgdRDi1m0XL5bKUoX4gLcGQ4gTofzlW0fkWTGqM7oaAo2D5x5HcalNUASjMt4RRIugkCwlRIp3n2ZCjKLDqAQTlfovFLLvQIres0y8Bcs4B3StuxEFreiJAFNVzym4ciQxPE0KXNLLREE/Vg0L8LMTInDNMFbF4Rq1mBIjgLPOx0mdh15c/psptnblY8BplQcL7J+BqE8CzSpF3z24EEJd8z8ip6spsF9K76jSNDYmpvpmGtABbBEchSrOcrDBfXUoBZf91QOKmjR7csI2QUN8frWcbawOVnOxA3xSntIHXNvvTBC7HPcsFfXRMtgRa/AFL4zYRJPq6N4q7umedYrMiknDQ33R0TR8pZZNx+EAyQYpHLNzdrs3R2fx815Z19XxkHH1WTGxrs7nICLmQYBDgpizByXXNGjckezfJd7qTOqShHfeIlyNe0p1y3U98b4orgKR0GK7DuW/kUWLeI+GuQWIQLgfQlmGP7tnn6GHbg5Qbbq/SLMTQTjCe9BrdTU2N1JEnJzb/76Zo8oedOc16si13SEIlrEJJFJXQSV0oQkf66YHDkHMM03Kye3DmDqL3c9rAvEBzbSrkU9AxAHMVNsfrIAZ3gWrFBAY6FRH0KKA10vxc+NF6294DPjJpNzxMe9hGTphnm3q58xR6zqc6NMovUeuNgGS1ePMs1zNXy6kZsTDNGHIJsAprIWZmOhk+mwp5a6sU2TCXi+IkofbWyyCVXC/JDEv3x/JfTacbVM9mTBDngK1nBlye+n8I9PiNtYKDhJIE5DtNpvEjq7gbIvYQYfpkfBWf/wRirncQ4I5FiX4uh 4tnHfhIu PaRwkNmi9zbOuBmfsonrlj9KMUdCFXpLk6wD6i/sC8a6XjWgW8jTHJOgH8zVm6ecprKIBldYFuJDxXE26GX8WHJ9YGm2qAGYevTeUHa6VFlFxTCuPYJCvOcVjhR6ONgMkBn2px8iIguC4siW1NDfLSunybFtwUBJD+tMaketgDKu0yqiHd7Y2zjkaQ5sBveNtr0x/WDITVRBt0+8nq+fbZMl1X2hEuHX60qfeBN9qPEZNUZxZJQQ71AGvjZ2Qbt6eLCMGux/fNH6HAbqocUPm6gC2PMaNSRMrc/DfAFO4yYXp4XzTaFG7JtlxFYUD2vpp+isCuD4ixOb1nXW2NS1mBXZO5yzNzQvSMji9tx6GLu6knoZSAzcxrFQfm4lh003q2kSk4nWDOcWLhNpyidZLCKRDin6t3dBFJCvgTH05dZTknUxJwwsC2R1crz6qy8eUGvmpKdo4/HoJpiPQfuZ3yAm1r1r/TrCvuksVluuPpT8rPcmsD1p7RiJR+CQ0ryP103hT3Wi5Nrat50c= 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: >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index d00b85cb168c..cb19150fd595 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -1570,6 +1570,7 @@ struct kvm_memory_attributes { >> #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3) >> >> #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd) >> +#define GUEST_MEMFD_FLAG_SUPPORT_SHARED (1ULL << 0) > Coming back to this part of the initial mail: > I find the SUPPORT_SHARED terminology to be super confusing. I had to dig quite > deep to undesrtand that "support shared" actually mean "userspace explicitly > enable sharing on _this_ guest_memfd instance". E.g. I was surprised to see > > IMO, GUEST_MEMFD_FLAG_SHAREABLE would be more appropriate. But even that is > weird to me. For non-CoCo VMs, there is no concept of shared vs. private. What's > novel and notable is that the memory is _mappable_. Yeah, yeah, pKVM's use case > is to share memory, but that's a _use case_, not the property of guest_memfd that > is being controlled by userspace. Looking back, it would all have made more sense if one would have to explicitly request support for "private" memory, and the non-private (ordinary?) would have been the default ... :) > > And kvm_gmem_memslot_supports_shared() is even worse. It's simply that the > memslot is bound to a mappable guest_memfd instance, it's that the guest_memfd > instance is the _only_ entry point to the memslot. > > So my vote would be "GUEST_MEMFD_FLAG_MAPPABLE", and then something like > KVM_MEMSLOT_GUEST_MEMFD_ONLY. That will make code like this: As raised, GUEST_MEMFD_FLAG_MMAPPABLE / GUEST_MEMFD_FLAG_MMAP or sth. like that that spells out "mmap" would be better IMHO. Better than talking about faultability or mappability. (fault into what? map into what? mmap() cleanly implies user space) That means that we have "mmap() support implies support for non-private memory", I can live with that, although some code might end up being a bit confusing (e.g., that's why you proposed kvm_is_memslot_gmem_only() below). > > if (kvm_slot_has_gmem(slot) && > (kvm_gmem_memslot_supports_shared(slot) || > kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE)) { > return kvm_gmem_max_mapping_level(slot, gfn, max_level); > } > > much more intutive: > > if (kvm_is_memslot_gmem_only(slot) || > kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE)) > return kvm_gmem_max_mapping_level(slot, gfn, max_level); Hiding the details in such a helper makes it easier to digest. > > And then have kvm_gmem_mapping_order() do: > > WARN_ON_ONCE(!kvm_slot_has_gmem(slot)); > return 0; > >> struct kvm_create_guest_memfd { >> __u64 size; >> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig >> index 559c93ad90be..e90884f74404 100644 >> --- a/virt/kvm/Kconfig >> +++ b/virt/kvm/Kconfig >> @@ -128,3 +128,7 @@ config HAVE_KVM_ARCH_GMEM_PREPARE >> config HAVE_KVM_ARCH_GMEM_INVALIDATE >> bool >> depends on KVM_GMEM >> + >> +config KVM_GMEM_SHARED_MEM >> + select KVM_GMEM >> + bool >> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c >> index 6db515833f61..06616b6b493b 100644 >> --- a/virt/kvm/guest_memfd.c >> +++ b/virt/kvm/guest_memfd.c >> @@ -312,7 +312,77 @@ static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn) >> return gfn - slot->base_gfn + slot->gmem.pgoff; >> } >> >> +static bool kvm_gmem_supports_shared(struct inode *inode) >> +{ >> + const u64 flags = (u64)inode->i_private; >> + >> + if (!IS_ENABLED(CONFIG_KVM_GMEM_SHARED_MEM)) >> + return false; >> + >> + return flags & GUEST_MEMFD_FLAG_SUPPORT_SHARED; >> +} >> + >> +static vm_fault_t kvm_gmem_fault_shared(struct vm_fault *vmf) > > And to my point about "shared", this is also very confusing, because there are > zero checks in here about shared vs. private. I assume it's simply a "kvm_gmem_fault" right now. > >> +{ >> + struct inode *inode = file_inode(vmf->vma->vm_file); >> + struct folio *folio; >> + vm_fault_t ret = VM_FAULT_LOCKED; >> + >> + if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode)) >> + return VM_FAULT_SIGBUS; >> + >> + folio = kvm_gmem_get_folio(inode, vmf->pgoff); >> + if (IS_ERR(folio)) { >> + int err = PTR_ERR(folio); >> + >> + if (err == -EAGAIN) >> + return VM_FAULT_RETRY; >> + >> + return vmf_error(err); >> + } >> + >> + if (WARN_ON_ONCE(folio_test_large(folio))) { >> + ret = VM_FAULT_SIGBUS; >> + goto out_folio; >> + } >> + >> + if (!folio_test_uptodate(folio)) { >> + clear_highpage(folio_page(folio, 0)); >> + kvm_gmem_mark_prepared(folio); >> + } >> + >> + vmf->page = folio_file_page(folio, vmf->pgoff); >> + >> +out_folio: >> + if (ret != VM_FAULT_LOCKED) { >> + folio_unlock(folio); >> + folio_put(folio); >> + } >> + >> + return ret; >> +} >> + >> +static const struct vm_operations_struct kvm_gmem_vm_ops = { >> + .fault = kvm_gmem_fault_shared, >> +}; >> + >> +static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma) >> +{ >> + if (!kvm_gmem_supports_shared(file_inode(file))) >> + return -ENODEV; >> + >> + if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) != >> + (VM_SHARED | VM_MAYSHARE)) { > > And the SHARED terminology gets really confusing here, due to colliding with the > existing notion of SHARED file mappings. > kvm_gmem_supports_mmap() would be as clear as it gets for this case here. -- Cheers, David / dhildenb