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 F05A5C83F1A for ; Thu, 17 Jul 2025 17:00:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92A238D0015; Thu, 17 Jul 2025 13:00:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D9428D0006; Thu, 17 Jul 2025 13:00:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A0F08D0015; Thu, 17 Jul 2025 13:00:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 652AD8D0006 for ; Thu, 17 Jul 2025 13:00:09 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 34BD68018D for ; Thu, 17 Jul 2025 17:00:09 +0000 (UTC) X-FDA: 83674369338.09.C802FA1 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf13.hostedemail.com (Postfix) with ESMTP id 616EB20015 for ; Thu, 17 Jul 2025 17:00:07 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=OVYUmFvI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of tabba@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752771607; a=rsa-sha256; cv=none; b=UcNVvRJlQgIIqPeti7aA4iGVIa67KD1znFs3+Vq23q5SKaJGJAgMXjuCXbfP/My+tydl/W loL28QqBWDk5fFFIQYEt0TQihT86RqxymzeZFiJFuSZmAUFBekE0tfFZQg9VwvhQrTZoxl HmdRboL2ThE2Q1owJazwRDAjX5+Dqjg= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=OVYUmFvI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of tabba@google.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752771607; 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=oU8OEN8DiLQiuJ4IMSJ9Khs9v4CHN7kHLEKR+HRpsD4=; b=xKy7EVBR/ieRF7qykHUeiBTDN2Z5OY0t6BC7Srvnh/9k7q0lCfPY8er40QdT9xdioU2V4c Bxk4wBxYbHCi1p7KJvqMgQphXpldiXqQftBG/MV1UTxdsSp0SV3D4VQWNiiKnShrBGOOMn AzwE1MuKsVKfa/oSvN+pJzYHRBioiwI= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4aaf43cbbdcso5391cf.1 for ; Thu, 17 Jul 2025 10:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1752771606; x=1753376406; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oU8OEN8DiLQiuJ4IMSJ9Khs9v4CHN7kHLEKR+HRpsD4=; b=OVYUmFvIijZLUvtZy6Qe+oDXYo/w8ZMW/4Ut7esTaNlSsM2raNNZA9ujDW1CcU9UiF tJ8kS2ECWQ/uS/Ey4L/gxpPtjBRLDytGNH5o/UvjWZ6znVjGFQPGN8MnGaFzozYxqHEc a2ezN57Zc0twQjmSaRyLMhnhVkJ0kzvMMeoZU6DPOfgiBrmyfqjf2bUGQ48mlwvX1iAw 5hmLF3Kt//BdfzxtBXyx0GHPdo8RM+iN5o9mmYNIzbPW15PTMG/QH9RaqvZo2QqEmCWP luCIb+zRe08rOl+z2wIYQZgHLq9FxssFzvQjTgCTm0PKc5o/zaALLYUtmanV3Ofd/aS6 kDrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752771606; x=1753376406; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oU8OEN8DiLQiuJ4IMSJ9Khs9v4CHN7kHLEKR+HRpsD4=; b=mg13cgER/6Ew6CKI7AeXDEGPSRdqjoFK/FWxW64psNCOaGz0+9EmdxtWrSsPL9jYoV JNER73BtN4nPs/ZcCfqwvXq6VcnV2ODbPNV/m5dMgUGITwvzcG+ou4bv/0qh3J40VwPk pqaBPGoL9swijqsHRVKN96pnswvBkTPaP+KX8Ow+WN5wqo9GWYPi1y4d/kpfYJwTIx2d FOXKVtj6nY0lL2y1BdkFIIpUAo1+1XpQiOvYlAvYq6b5iFPlsy+XhF67NQjFC5UP9iJf 4FmABB+qJGREnk3SoojDpnXG36cTTIg1ayE0TGcCSah0pxt2IgqRLsmGTPRkZAPLXYU7 Qz+A== X-Forwarded-Encrypted: i=1; AJvYcCUNoas3NXQ3DNab/MyjdnPwtrmH83FOZiTAxgdz+gLWwPcpnTVlx9LJHybk1QaILDn3OHlo8nmSjQ==@kvack.org X-Gm-Message-State: AOJu0YwHc2sL9+wAFjOpdLkMR0g5GHOUBDIO2ptsgoJ/6tUW+laMoRh+ GPUUa6RgzVtFoNwRHmvowlYSs8Sa1sNbljJwEOHMrNi1zp/sRYih7OzrvYXREpiKF3VxxGaZtiQ Fo/GFyYga3SxvlwefFw/2VnA3FucT6zja8ytDCFwB X-Gm-Gg: ASbGnctj2DmmzVpIfvqZOFvlayzXdd45gktN5XHTlkxjvXmGfYSwbAlUpT1QA7BNTVT qJPeHp0RgDSonnHrK2KoXAupOqzoe5PVSnZVw136dDGKd9jbQcKmmMBwal4Ng7IKRbThuZO2zqD baJYq4aqVMSFIutQvjQGGvigpd/SaNKGFt5ttSr8RYWvD4FF9uG6px8FR++9gSK9LpwaCnfc2my O1VwhSugONTk6CUbA== X-Google-Smtp-Source: AGHT+IHeNpR/+BN6xdHvYv3j4QgYq0wNKWKEZESgam6TiVIr9nAQ68C9bCDfOK9/avU/Gq6vxcviQoc9FPaew2iDRIg= X-Received: by 2002:a05:622a:8d04:b0:494:b4dd:befd with SMTP id d75a77b69052e-4abb1327719mr384211cf.8.1752771605706; Thu, 17 Jul 2025 10:00:05 -0700 (PDT) MIME-Version: 1.0 References: <20250715093350.2584932-1-tabba@google.com> <20250715093350.2584932-5-tabba@google.com> In-Reply-To: From: Fuad Tabba Date: Thu, 17 Jul 2025 17:59:29 +0100 X-Gm-Features: Ac12FXw4Rvcuc6rmyInnEzxFUojvTpTYKEnaNr9lZYk_ew7ONziPwEn2F1tG90w Message-ID: Subject: Re: [PATCH v14 04/21] KVM: x86: Introduce kvm->arch.supports_gmem To: Ackerley Tng Cc: Xiaoyao Li , 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, 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: 616EB20015 X-Stat-Signature: ycapctdkqex6n44nh3quhbciqekefgfn X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752771607-843302 X-HE-Meta: U2FsdGVkX19GbcT9DOeKyjMqgzKWksADqrSg66F5IO1ueyAK0N2Z6aaZjDEraS4Ys2Cmf4DxMtlPr7E/82Te5yuZcY23m1FkyEzlr8Z1Shxko+TLqsqWE6G+6ajrGEB4nEqVDEN3KC7uufnOeZBVc9fnimevOdoDb4Qf6TkNrC6nGwdo6d4olNytFVV1pzFKHlG3xfoNCrQTTY7Phmh+38TNTdz8lmGJifjz/ddRGq7PrgG90lE10koHAfB+jo+EtfNwyC0fkXSTceclTIG5LinNw/XgRZ7Ows87iFm7ypeKDADbOkTxelnBeuMQ4HxaI2cmP7xKakKOp4Yu8LzLCwaims9ipUl7uKkGwHLGlEvZA8M6xf5CaNvAgsX3SB5XED2Q1xrL3EE0Oy0dI8XBtoYK63xpOKiabje5Oow3KOzYfn4xjfB5ojl/DZi+pF3nJnbTgYkUVtQvDjKLYH2AicGooRfcmEnPw4U2Jm/HVFldtl0d8dQ9CkJbIWNDOKmt3Fr1s0EGjeBT0CAHSAM+J1mfYcZfoFaBma+xpdHeNCnPQz1jKz4yArHN1WRinUsBSBbmGbalvlgeYp18NKpUI8U1SR9FnI4rlXX6BdQkQsRh2ALNpDROD/FQGLH62ig9dHQv5dorDaIVB0LhPuSVHGcW8WbEcWG1T/qDmjwaB0ZjC7/MjeaT8GKkQ9oE+Nu87zAm4Zx95cJ16TS8VqQJgRlYz+WZOOLn+GgS+6Ti9j8Tbay2U8WmYb0HtlhikTJwaJker6k8o/7tlZJAmRZEXdLf55js0N+AEc4m+7JRU7IyXknUGmUiP3I+NEUs2D8l9BindY3UK+EcAriRn6jWBMy/OFOYk/xJAXcdvxGRErCBrNwYG4+R7tVph4l8u2i2HG9HC4GeSAM1BAU+51xWNzqb62a9w7dV8QVoxGvumuDywVzo3Y/au5/anik/ewB22gq2lA0awtvtBf7QmZs AI5xY/AH EMHAqHAHuuUaryauE1WvSMgYN5rjnIui4bFswyS7jssIhtcrepWbryaG2G3pgJN+aBWc1JBKS6K/iZdgkTrzJNo6bbId+Efd6XXw2cDN1S9DdfJZ+XlzDhyiL5kFpZ1Xb2rYIRJf1E1nZrEm+zw7pb+L3PiHbbTDQ+GPwLr0qvfObbanqxQ8MUwY3psyoRuDe32LFroIpoR3y/Ku+1Dd+b9hHp1wGGlx22r/9ZGlwzOYN3uLncfSRb35M4HXYMYJXCLH4yEKYg6s3/umIL9y2vmnIHnJLa53xqSo3eecryrCudaKWG9TnvJdyHNxzKfpzj6L3H1uklpxJzrLYLdD9rSTCmBJ4RgNYup8kFwh6TLD4+uyQGNmHH/iSEiP+4YHgqfIY27jiMVq6K7LxY47LKBhhZw== 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 Thu, 17 Jul 2025 at 17:50, Ackerley Tng wrote: > > 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? I do think that, in the same manner has_private_vm is a field, this should also be a field, and for the same reasons. It would confuse things (in x86) having one be dynamic. As David said, let's not nitpick this :) Cheers, /fuad > >> 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