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 3C3E0C83F1A for ; Thu, 17 Jul 2025 16:50:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8536D6B00DB; Thu, 17 Jul 2025 12:50:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BC086B00DC; Thu, 17 Jul 2025 12:50:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 609738D0006; Thu, 17 Jul 2025 12:50:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4766C6B00DB for ; Thu, 17 Jul 2025 12:50:14 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BBDFD10C004 for ; Thu, 17 Jul 2025 16:50:13 +0000 (UTC) X-FDA: 83674344306.23.CE2AA55 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) by imf08.hostedemail.com (Postfix) with ESMTP id F22FC16000F for ; Thu, 17 Jul 2025 16:50:11 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t6mYofO+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of 3wil5aAsKCEUhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3wil5aAsKCEUhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752771012; a=rsa-sha256; cv=none; b=qicYGEPR6NAeZDTP9RGHFp8GYCFcjTGe5izZxHHtnXOwzKqO5gMDfMWzCtJSrU/ghK+LzU 9p9SUNQT7Ybs0qVeBDEcQTe/cEGdLR0xPLHgYV0czFi2p2f1flRvcY10kS06ItFSDTuBUR H/FvnFW2WcnvEtfJ78cxYwZ5BwHKmBQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t6mYofO+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of 3wil5aAsKCEUhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3wil5aAsKCEUhjrlysl50unnvvnsl.jvtspu14-ttr2hjr.vyn@flex--ackerleytng.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752771012; 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=WBAzc7UgvLX+B8PzHVBbV8hcGwtUEb1k8RUWx3wr7P8=; b=vpneiugrqaGHHEzhP+6zOCOuv3CCbdwTMNCejN6ULFSViMMN0GWYu0mWXBHZv+qblBaLx2 YuCFTYScvE9b9UFSUS/2O5FLjaa7CopYQh+sxX5bSNUoVXzX1UvM1oqGYDCdiGywbYJ1Zj SwVLwX7MbkKWcuQVAs8eaGcDcIevawA= Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-3132c8437ffso2079819a91.1 for ; Thu, 17 Jul 2025 09:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752771011; x=1753375811; 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=WBAzc7UgvLX+B8PzHVBbV8hcGwtUEb1k8RUWx3wr7P8=; b=t6mYofO+OsxtRfFDTYol2g/4MRX9dm3WWtsm9Qiz7ik6+5G4kTAcsJgs+mPRwQVHUS SmO/3C5RzwKveg693Z7PXcbXVzWGHSclo/vsHqtWrM0Sckgj1cI5NeD5CToeyC53QBMk ov9Z5Fl3xzPsVARnCjfAcQ/hAGsir1VfmDzcAJrGa3HuvxGErg6WyWTl9btrnhqUbw3D 0EVwFVngRJEwHfAP8BtEYVkQD3fUowcnsrZwBOPw3et2B22kFkwN+/cDgvVLVegPFIOx SeSzZksQn+a+4T8Vi8EYDDqLPL3k4Qz0w6sUudz0SKKivWXA7xY1kxavontKkD6X71NF Ug1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752771011; x=1753375811; 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=WBAzc7UgvLX+B8PzHVBbV8hcGwtUEb1k8RUWx3wr7P8=; b=fLp4FWA3dLoAqJJql0W8zT+9PP/fKOWe1/WzV1FA6W3ogxGFQ/9zmaQ2fPNJ9zXZXP iODIKtOpmjRxXGCOqNrQuGIq2eETAUxS+mVlJse/qu5QO2fUtXSVAzodLiyJ0KBrNMlD R+48uYUiFLid4L7syGvDrFLgKOoWINzOf0tisD8AgcaztGYuWgreJLHoaY5N+Ud3kB5n FzctI56CXzlkqDKv7ySbFfVIXYZq7oAN7sFdj/DJHPYsJOi/8P0Ec+2o5qEYrcs4N91M 5AAWLjU/HUT0XECY9l9EDdJ0wdGWJroP8iDvVv5DrXHdY6ThdASSKPtlRW77iehL/x1J 1r5g== X-Forwarded-Encrypted: i=1; AJvYcCXYIhELMi/PFNHV3WDc440SzZxUVw+9cEJp3Mc2vECkp7EuDlE0vekaM2ZCQZzI1l/mem3dzl0BvQ==@kvack.org X-Gm-Message-State: AOJu0Ywn2uuw1cwy0Z57akFzeWJ6R1Z4DWs90O8OCbiB4P4jczqiHLII 4MAZGRrWyXuMVHNsbF6zC6GmSzmh+SlCNNBB7Q34cEe7o24XuPGLbW1p1CNJ5GEua5/hE1IgRO+ LGdbXoyYxvzPpWldxi+IYrScMEw== X-Google-Smtp-Source: AGHT+IEhDg9xNtK2OOevEaVdQD/8F/x32XlKvxnbxDiNek4tVELQY02FrDg+/mKgpmUj0DqZBQWsfDifCuQhasqQTg== X-Received: from pjbqo11.prod.google.com ([2002:a17:90b:3dcb:b0:311:7d77:229f]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:270b:b0:311:df4b:4b94 with SMTP id 98e67ed59e1d1-31c9f3ee9dcmr9740819a91.4.1752771010723; Thu, 17 Jul 2025 09:50:10 -0700 (PDT) Date: Thu, 17 Jul 2025 09:50:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250715093350.2584932-1-tabba@google.com> <20250715093350.2584932-5-tabba@google.com> Message-ID: Subject: Re: [PATCH v14 04/21] KVM: x86: Introduce kvm->arch.supports_gmem From: Ackerley Tng To: Xiaoyao Li , Fuad Tabba , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev Cc: pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, 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, vannapurve@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="UTF-8" X-Rspamd-Queue-Id: F22FC16000F X-Stat-Signature: 4w7dymej5bnmryw36xt9o1gdtwrb9ptk X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752771011-325019 X-HE-Meta: U2FsdGVkX1/RjLd3PCsoLJ6z4Nix71J6CLc3bCWVaLzKsi5Hj4M/zsOgFqldZMn4tSIAEd4OjCaT6dbJZhCs/wfkWHy3/pSt9eRz9XjUK5134C3bMM5iwIP39zGbJKww6RX5fHp7EhckizUQykRfXImyd34+om6HMFaOQuyjKAuhbFRxu+6bSWH1T57iwAGIYUF0yl6li3FSrM/bnfrvcymiRgnL3kMHNDroMMo1oNMwaOh4/t+2msU5qiILHCYMZ5X0/NAcQ9lsTosZBikcsBW0gIv4EFO6q1dwmlKFxg5ezVjKU/Iqf2sPNOQNe3xDBZOikfrTtZtBlEeHG+aGyKu5iF72NzZmAwI5TJH8xljWLgNmIjq2FetUrccCmj9yw73c4n0U450GVYUjQwvAqazJYAfJSWfxkD6BBvhs6viEpdZFQISppbVTmQUZdyBoC8Dn8lKy3P5WqAH6JWm8ITDKLhYaDoaGKKCsJUfwdPg23caUMLmItPFJZrNg0xQe5uOLmmkEQei3BlwkYVtx4jbOuuADLPuLVy6b8eIXpKOLsie3HABvxGARmZVWNYU8ezo1PYcC00QTilyE41UPC5rjAHVIMkGWvI+4Z9nEcKfJ3Swoac8OHS2a5bcOltU7SKuYQ3rrA8aA1D4kHuRrsWcn/2ECpjfVBsEaDEWV5Y5izo8cdmTvbOfhAFxqaSwdtGIG9tjLOUr2BG/xm1+hlvqqUMsHw7lCGSWkRNuWr65p+YdnCXAF4k3fwpbk8RA3TLTX/+JFs4x8Ykm4qnOCpksrzrUM6LzPvxLoTWsakEK0kfBqyB+21FrDthPXCjquEQvnAw16y9o6B+XCMZY5K7ld8NIFYeCfWkXNAw1EQ6qrXCE5Fzs2eyNMrkwGNvkEWUHdIL87zcxSz53Pn2AKKiozRLgOrJiUlVCrPP4ka/nFWgaIO1I9Mw66xZZiULI/BwAcGeVCRCuoqGuCjeR aq7TFf6k O/DOiChiTL88rXQJ/4I7UF6FUcAtKMFX9H2lcHT9Bx6ltRmZ+XaqatXnl0cEybHEcNAhzWX9okBCdOi4Orpl96TQhUZEhy5M9RmwacyoYdTr/680V8sAE8mwKieXW0pVE3750nI6LdHFQttgLg0Lw1+Gyr6V3cewcLzqWSEL94og8CEmtuw2f6qBkOVPWc/CXEPhs6LwKDZy/UCRydkxQSHrSvTTI9Vw/WHtfciwPYfIfp/XXNmEDfxllG3z16FQRylh5QY5qcCrhnRLM66Ko5xlM3/nCQaOQCBa1K5NSusYdKIbQsoi4SUvbgdVFb1bzgDhALZocY7tTpCFhB4stV8mJH7nu84wPG+I63z8p6AjWsaBwcdfxtqRpuv0JHSZHJ1MEipk0iwRlCDxoW+juo75jfEamkoIvaPpzbnPVygP4hM2jZgAK9hWtU46ZnyZY6s4D8Yh6zawKHlkX7VjD5S0JBHCO4Km2IFYkFp0HSrXQIjG0k0+LWBHMfbKmgAI2scqc/V7rvJ4sLtySE5U8EleQTc9V/2QnN4s/PoBi7sGH78STXsP5kkCm600X/j5I3wAdd9STVJF0yPWZC99XYEMV0IoSOVZ73aaNqhfkRnwANFCwWuAGOj/xaplFYFL1NPig0DA5TaTfscA++oTXlxzpo2FV2gLrNrjYD6SXVt4kX6A59ImIu4XqP8hDpDxYv2Y45yANA0Nll62L/jn5xQf+FyryGcEYL4Tuu0wxHXeZoi8dZsfCw81D/w== 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: Xiaoyao Li writes: > On 7/17/2025 8:12 AM, Ackerley Tng wrote: >> Xiaoyao Li writes: >> >>> On 7/15/2025 5:33 PM, Fuad Tabba wrote: >>>> Introduce a new boolean member, supports_gmem, to kvm->arch. >>>> >>>> Previously, the has_private_mem boolean within kvm->arch was implicitly >>>> used to indicate whether guest_memfd was supported for a KVM instance. >>>> However, with the broader support for guest_memfd, it's not exclusively >>>> for private or confidential memory. Therefore, it's necessary to >>>> distinguish between a VM's general guest_memfd capabilities and its >>>> support for private memory. >>>> >>>> This new supports_gmem member will now explicitly indicate guest_memfd >>>> support for a given VM, allowing has_private_mem to represent only >>>> support for private memory. >>>> >>>> Reviewed-by: Ira Weiny >>>> Reviewed-by: Gavin Shan >>>> Reviewed-by: Shivank Garg >>>> Reviewed-by: Vlastimil Babka >>>> Co-developed-by: David Hildenbrand >>>> Signed-off-by: David Hildenbrand >>>> Signed-off-by: Fuad Tabba >>> >>> Reviewed-by: Xiaoyao Li >>> >>> Btw, it seems that supports_gmem can be enabled for all the types of VM? >>> >> >> For now, not really, because supports_gmem allows mmap support, and mmap >> support enables KVM_MEMSLOT_GMEM_ONLY, and KVM_MEMSLOT_GMEM_ONLY will >> mean that shared faults also get faulted from guest_memfd. > > No, mmap support is checked by kvm_arch_supports_gmem_mmap() which is > independent to whether gmem is supported. > >> A TDX VM that wants to use guest_memfd for private memory and some other >> backing memory for shared memory (let's call this use case "legacy CoCo >> VMs") will not work if supports_gmem is just enabled for all types of >> VMs, because then shared faults will also go to kvm_gmem_get_pfn(). > > This is not what this patch does. Please go back read this patch. > > This patch sets kvm->arch.supports_gmem to true for > KVM_X86_SNP_VM/tdx/KVM_X86_SW_PROTECTED_VM. > > Further in patch 14, it sets kvm->arch.supports_gmem for KVM_X86_DEFAULT_VM. > > After this series, supports_gmem remains false only for KVM_X86_SEV_VM > and KVM_X86_SEV_ES_VM. And I don't see why cannot enable supports_gmem > for them. > My bad, my explanation was actually for kvm_arch_supports_gmem_mmap(). Could the confusion on this thread be showing that the .supports_gmem is actually kind of confusing? If there's nothing dynamic about .supports_gmem, what have we remove the .supports_gmem field and have kvm_arch_supports_gmem_mmap() decide based on VM type? >> This will be cleaned up when guest_memfd supports conversion >> (guest_memfd stage 2). There, a TDX VM will have .supports_gmem = true. >> >> With guest_memfd stage-2 there will also be a >> KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING. >> KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING defaults to false, so for legacy >> CoCo VMs, shared faults will go to the other non-guest_memfd memory >> source that is configured in userspace_addr as before. >> >> With guest_memfd stage-2, KVM_MEMSLOT_GMEM_ONLY will direct all EPT >> faults to kvm_gmem_get_pfn(), but KVM_MEMSLOT_GMEM_ONLY will only be >> allowed if KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING is true. TDX VMs >> wishing to use guest_memfd as the only source of memory for the guest >> should set KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING to true before >> creating the guest_memfd. >> >>> Even without mmap support, allow all the types of VM to create >>> guest_memfd seems not something wrong. It's just that the guest_memfd >>> allocated might not be used, e.g., for KVM_X86_DEFAULT_VM. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> p