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 3E3B1C83F25 for ; Mon, 21 Jul 2025 17:29:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CAA5A6B008A; Mon, 21 Jul 2025 13:29:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5B1C6B008C; Mon, 21 Jul 2025 13:29:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B71076B0092; Mon, 21 Jul 2025 13:29:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A7AD16B008A for ; Mon, 21 Jul 2025 13:29:45 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3B951B6066 for ; Mon, 21 Jul 2025 17:29:45 +0000 (UTC) X-FDA: 83688959130.19.7B856B6 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) by imf06.hostedemail.com (Postfix) with ESMTP id 67E42180014 for ; Mon, 21 Jul 2025 17:29:43 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2v6Fwv2f; spf=pass (imf06.hostedemail.com: domain of 3Bnl-aAYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3Bnl-aAYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753118983; 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=9OvpY0AOd4TKj+pOT3DzWszlAggjOKWS4p4sbX0uowc=; b=goxpYLdulf+K6BpweFefzS79By1pePUP46V7HLrR1t0b39FGXdrad2TMnM8gPZaYLi34CB 7OGkn5wBOJ3RHhAL8ne5JThSpsNgUdo7rSHhdE+VPvWcO1hIkfruUy0dJFatsxUhG2y68f pK+Ua+fZYr9gwyFCwjm+lWNXJANkRY4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2v6Fwv2f; spf=pass (imf06.hostedemail.com: domain of 3Bnl-aAYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3Bnl-aAYKCD0rdZmibfnnfkd.bnlkhmtw-lljuZbj.nqf@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753118983; a=rsa-sha256; cv=none; b=RuSKU7qjZxwZWqEXnGls+SxYNBDoNi1Iy1RdLISxAeT8liI05GEIA6FvMeQnPjBU/a+vo/ /xefYFmGPiF/29b2ESuFIZnNBs5B8k3z9Am91YsQl7SF022P7GYYYsBqNqnWsoMm/SCnH1 naOVyJF+79rV1vME/AaDS8Od/d/Almc= Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-31332dc2b59so3756987a91.0 for ; Mon, 21 Jul 2025 10:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1753118982; x=1753723782; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=9OvpY0AOd4TKj+pOT3DzWszlAggjOKWS4p4sbX0uowc=; b=2v6Fwv2f2bQzRi4C/Yp8Rzat4swPJlPDGaHFT7Htw/s6eI+gycDzpBqRk42jfvSBae Ab/BHWezodJLNAgmeRw2ueSIWziRscbdbbhMa5quAtuhHDe8hAri5+IMG2Boq7pKz7Pi /WTAzqYMcIrId09Y0Cr2vQalqgnKxftBWm+myvOWRTN9uB4Cxt90h0yb95U0GdWiMgX2 FptavE4mdLW7f/gQH7NXg5wot/X3UHMOSkiV9RpcTzas7vvIZYp584RK/u5I3ZT5p9lK bfaJE8SxpxXG9t0v3vLgpGEi1YGvjR7UOlDxZEt/7Ym0m3XNh5FXmumLkgq4WX169gaC KHjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753118982; x=1753723782; h=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=9OvpY0AOd4TKj+pOT3DzWszlAggjOKWS4p4sbX0uowc=; b=UzJkCDVJ1EL/Wxv2Pcv4ZxcJD+fP2mfokfaF/CoB19h22ibJTpByvy3yYBlzv9Jpuq 2ybyTieiJ5/STYH6MU+K2wrPZ0I13vST9yl8IvBAo/M06+EWTHzkUs8ee8D9gfSONNis OB2ReFuCifcuMe/w9kJQuy0rY976ZaKiMNH4tjQK9zddFJNpdRaBxLa7SlP4glqWf/dB KgSluv3mRiks2g1GpVcAaFkSkw9RDsJhdx9pclkJKg9ACJaotSdZOST2IZ1uv350krjl SVL5J+cQbCMblN2SBihYF3iJ6OqIx+tL0vCWW9nSKhy7PWRSWbRmcPhLk1jdJzQTn9EV cjgw== X-Forwarded-Encrypted: i=1; AJvYcCXGEKxs71JD7NWDreKPTJDwEgx0aMwboBgEKuwW8eOIGN3rzdp6CuULFG1+B4yigTUTQViqSxnYAA==@kvack.org X-Gm-Message-State: AOJu0YwU+wsKbRyDArvzmDjiqgnVtswmqN4Knld+jMxHgr0AFyej1Hv6 p05jp3rsIyMv02KntgziWHQ+ZZjAwlIj+dRcLtXsyLNwxnmRtRW22VzIGGPnC+p7ucm7GEpkZJw U6UY7qw== X-Google-Smtp-Source: AGHT+IFhRVu6/b0PqYJW3muXwv7nDoSYEeLC8OqW5axU4suctUJzDOyv4LU8g7tON33RpjxB06RUczbhKIA= X-Received: from pjzz15.prod.google.com ([2002:a17:90b:58ef:b0:311:ef56:7694]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:580c:b0:313:d6d9:8891 with SMTP id 98e67ed59e1d1-31c9e6e5584mr28813484a91.3.1753118982212; Mon, 21 Jul 2025 10:29:42 -0700 (PDT) Date: Mon, 21 Jul 2025 10:29:40 -0700 In-Reply-To: <1fe0f46a-152a-4b5b-99e2-2a74873dafdc@intel.com> Mime-Version: 1.0 References: <20250717162731.446579-1-tabba@google.com> <20250717162731.446579-15-tabba@google.com> <505a30a3-4c55-434c-86a5-f86d2e9dc78a@intel.com> <1fe0f46a-152a-4b5b-99e2-2a74873dafdc@intel.com> Message-ID: Subject: Re: [PATCH v15 14/21] KVM: x86: Enable guest_memfd mmap for default VM type From: Sean Christopherson To: Xiaoyao Li Cc: Vishal Annapurve , Fuad Tabba , 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, 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, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, 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 Content-Type: text/plain; charset="us-ascii" X-Rspam-User: X-Rspamd-Queue-Id: 67E42180014 X-Rspamd-Server: rspam06 X-Stat-Signature: emk9oyhfofcesbc4ctneyyimb8acfh8t X-HE-Tag: 1753118983-186455 X-HE-Meta: U2FsdGVkX19UvSyfpA0JnNFa1NcuaOSrnUDEvBi2UUPSjXD62Zw2KJI3b8fkwDkYL+V/MmCkxdIWbZMj6rqeTqiSmUMQO2UaBwP1i06ReKKGc9PS9wIHOzpyNsXVSaneqnbCZM+kAsUFu2WKdgp5tjp5jSQOGRg1PKssGteOXM3D1vp0ttXWYFc+LGQ3OT1YwOmSlk/wGZ4jIOzf5vRe951MVXRI4jpjEHBc2UaIplgBPcyuHmzxJWKUKpdx5fZCJjyGuTf+9ks0i9rTVSZMmPhErZ2+Rr7Ml3QroonaUh5m8BulAIBJKXPHwJtRcVQSBHueQ248flOkUX6RQLyR+RN6plZWZgUZD0abMH2mYby5LXFc3Wh7D5Dta+oHntT9wlXEI7njea1w/U7svslelgiK6ElfN/+11hUWKFRw3qJtBRJch7osMWsKJ7z2NI0eBA0qRgu3KGmZlLTdLyhgx+1wSkVH+j1x24/XSJK1QSLBCw4K5oBeGc2AU9rcXZglv/xLGpFOKajSvVirByM38ZsNiK4xA/FhbDJFAPCx3abcSoMg0d8LyaKButNBCzv73UU5L0euRJM2zKOqbhIYzqhYXnmIyC6itJUzXOJyD2HE6KSeSIWWLTkZtTM5P3EntVGajk20FMhlpweOa7fXsTrkrIuJbw9nXor97vRufXxALbzlmQKg0Ylv3xE9dxlsTN1rfBWmqLVyCITxoyzmF4pt1YRFOAXVffkRQULyglkqoPKp99eGicnzoDrDiV1/T0QphZbzecuIBhDInqYWLa0Udiw/2fPJR+vaIdRCptfQpMs9Pla746QvGmD73ejTOlrrXVToFv2npGXp+1Hhvj52aLl0TRF8WtdEVz9vYgeBHJBfcTd3ffXi6oGadY2NtQqxU2o/OywgGP4y1DxbB+L6U1E/fAmLJ+TyVPdtke9KBuS80LwETudKtI8ao1Z4TbSl3OWbOcU54FIPdIK jrJyf2Du uYsJPG5D1FukH6nc8AgA/S5SZq3UQ30HTJWD8tGDTEWiH4sr2qmt9FofzNd8WMmXbApyy2IpKNUJA3SvvItdTaGO45evoEjbGEOZ2cUdRaAgSjSKel+HnaDia/arS1zcPGqsuUM01xO2woj6yqKaWHOqtVFHoIVbRfOPjL4AVnTYEtYQQkSFtpaQFGUWkuzz+MWN+LK+QapScraZIVSYwxeedP2x+VcfVJ1tsRkmDm4+mYl/mQ2iQan/ubpa+861LwoxcNGL/mZqNns/xkKySHGYNQxwoyejB4HIMmjLHVHXWiFaNuEb/YORV9326gjnFVYogsEopMkRwRbNtGwmFoDb92Lg7PB2JMt5Imk3k4Bq2/3yyNdA5Wlgb9IHXAENBOH33scUz1S0cCARu0hQt6+hzuMJGGK6lsoU+Z5xluznGTaw4xDmOyrmeIfLKxfXDAffXZdTnegcC9hOg1TI3bErFV7LcXvbSftwarBvnpHHLH6ndjjDaDFtxT2a3fvcNw8HEs3VdR8GaoXN/Nt9lc23AsPdofAS42Phj+qYVmMKTOgvgkop/kCftT1unOETAAplcd031MODA9M9KIhQZy1RNvSNw8SkKFntFJCSvOWVD+/8KD1p+BuvMtT0/CA0nckYy1/HV3nne2I4vPkiy09fqADMrFxyWJgCTyM/YhPityzybF4DQbLwxarxiNRVIw7NN5Cc269U/HLc= 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 Mon, Jul 21, 2025, Xiaoyao Li wrote: > On 7/21/2025 10:42 PM, Sean Christopherson wrote: > > > > However, it fails actually, because the kvm_arch_suports_gmem_mmap() > > > > returns false for TDX VMs, which means userspace cannot allocate gmem > > > > with mmap just for shared memory for TDX. > > > > > > Why do you want such a usecase to work? > > > > I'm guessing Xiaoyao was asking an honest question in response to finding a > > perceived flaw when trying to get this all working in QEMU. > > I'm not sure if it is an flaw. Such usecase is not supported is just > anti-intuition to me. > > > > If kvm allows mappable guest_memfd files for TDX VMs without > > > conversion support, userspace will be able to use those for backing > > > > s/able/unable? > > I think vishal meant "able", because ... > > > > private memory unless: > > > 1) KVM checks at binding time if the guest_memfd passed during memslot > > > creation is not a mappable one and doesn't enforce "not mappable" > > > requirement for TDX VMs at creation time. > > > > Xiaoyao's question is about "just for shared memory", so this is irrelevant for > > the question at hand. > > ... if we allow gmem mmap for TDX, KVM needs to ensure the mmapable gmem > should only be passed via userspace_addr. IOW, KVM needs to forbid userspace > from passing the mmap'able guest_memfd to > kvm_userspace_memory_region2.guest_memfd. Because it allows userspace to > access the private mmeory. TDX support needs to be gated (and is gated) on private vs. shared being tracked in guest_memfd. And that restriction should be (and is) reflected in KVM_CAP_GUEST_MEMFD_MMAP when invoked on a VM (versus on /dev/kvm). > > > > 2) KVM fetches shared faults through userspace page tables and not > > > guest_memfd directly. > > > > This is also irrelevant. KVM _already_ supports resolving shared faults through > > userspace page tables. That support won't go away as KVM will always need/want > > to support mapping VM_IO and/or VM_PFNMAP memory into the guest (even for TDX). > > > > > I don't see value in trying to go out of way to support such a usecase. > > > > But if/when KVM gains support for tracking shared vs. private in guest_memfd > > itself, i.e. when TDX _does_ support mmap() on guest_memfd, KVM won't have to go > > out of its to support using guest_memfd for the @userspace_addr backing store. > > Unless I'm missing something, the only thing needed to "support" this scenario is: > > As above, we need 1) mentioned by Vishal as well, to prevent userspace from > passing mmapable guest_memfd to serve as private memory. Ya, I'm talking specifically about what the world will look like once KVM tracks private vs. shared in guest_memfd. I'm not in any way advocating we do this right now.