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 CDB63C54E65 for ; Thu, 22 May 2025 00:40:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 429106B007B; Wed, 21 May 2025 20:40:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DA0C6B0083; Wed, 21 May 2025 20:40:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F0046B0085; Wed, 21 May 2025 20:40:20 -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 0FFA16B007B for ; Wed, 21 May 2025 20:40:20 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D88851D49EB for ; Thu, 22 May 2025 00:40:18 +0000 (UTC) X-FDA: 83468687316.20.8387079 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf09.hostedemail.com (Postfix) with ESMTP id 05DE014000A for ; Thu, 22 May 2025 00:40:16 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iQE1vGaD; spf=pass (imf09.hostedemail.com: domain of 3b3IuaAsKCFYy082F92MHB44CC492.0CA96BIL-AA8Jy08.CF4@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3b3IuaAsKCFYy082F92MHB44CC492.0CA96BIL-AA8Jy08.CF4@flex--ackerleytng.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=1747874417; 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:dkim-signature; bh=AKb7exaOpTslJM3RgwHKvEMlMgIHhiGGsRV2RCQWlUI=; b=Wv4MlzUrbjmyqtAOYBg0UoI6cZFBO8zZIL8rlliUO5XvBytWg3vxx1yWGFUf7115nWFteH nOdnIduGmFRWa8yM5A35TYtc+X0J+YDwtSqSf5mm0WYg76y6Hw5R2lVUdyX9NbnD6ySBhI 3ZrVhpoGwxyUPP5PPxRR75BLTB6o75Q= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iQE1vGaD; spf=pass (imf09.hostedemail.com: domain of 3b3IuaAsKCFYy082F92MHB44CC492.0CA96BIL-AA8Jy08.CF4@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3b3IuaAsKCFYy082F92MHB44CC492.0CA96BIL-AA8Jy08.CF4@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747874417; a=rsa-sha256; cv=none; b=4KBO2usNI2RTXPSKDPcNdn1uBfyy+t7Bls01FGzYk21ZeGCXtcUO3CjxDKKrC2xT8zZJng C3RFaaufkgt6luYkIwdE70tQS/SIsXsyTMkOvFUN5yELbd4TfvfNe/jGJmqUq2YhluHrJG 7tTAqbfkPtW6H/9rm6vlFjBwsSeCp1Q= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-7398d70abbfso10045153b3a.2 for ; Wed, 21 May 2025 17:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747874416; x=1748479216; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=AKb7exaOpTslJM3RgwHKvEMlMgIHhiGGsRV2RCQWlUI=; b=iQE1vGaD61o3RiPhpW0WgnNnJiWihk+zTj26kk+mfDElZF4sZ6Osly6WrS/qUoHaYn sOSqnhx6tUBTDshtt2YbrefYeU5VPncxSopl8AHDmVNWtPn5hC/gBIPDC43ZEaRzFk9J LC1vHHgzOj3+oz64FaZ+Dbe8RG+kFQh32oDqQJmXmaWDAmRPPYOOxhT1+VlWb6P8nlyf 80G4V8DXBlJnoGo2BU1q3yGqGnknpZSibigvGn+Fpz1FC6TXkCYUAAn5r296okXfvkG+ H/EVsJLmH5/5Po/fNEgdFhtMH1I7NtZxnrE/I/datgvjav1FDdV4fMqtlcFEolut70xQ 1XFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747874416; x=1748479216; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AKb7exaOpTslJM3RgwHKvEMlMgIHhiGGsRV2RCQWlUI=; b=qrao1FNctxqD+to/OR0wKEgdX7R0iz1l6nesj01OL/DUjE/grZL8adii5NlVbkBKQv t0KMpibqe/5Ou6imNtOFkBAU5W1Af4S8G7VL/Tv9qWVi+WGIkprn6J/hmbcej9E6tAkt 9rsVI9LNZUG/pMhAOYJ3m1+KVf2ZdwimbOf1MeBKMaoeK0kL8QjPuKQWjsH3m8duBYRh +av+7McgdNGDgm7LyeFb1o9pCEf6sMH46a9zHGWy5Ndnci4DQ/T9XYtrLvgkx35Nq0Qy TsBekGLCvz1hMSzxUJrtCCo10qNtco/lW8COmujK/0RK6i2km8Lmr9kOw6cPq0Cj1UMC NdiQ== X-Forwarded-Encrypted: i=1; AJvYcCXnP04zHdZmPsbiHpvKI7Cso88dKAlpQcLGqbHvlOlEwYwJYX1XlOhzDuUkHczP2hQCPxXhzQPqVw==@kvack.org X-Gm-Message-State: AOJu0YwJN5G6nM19IvwIO2IAmOk3owySGPk+eOzB5nCEr+bQy7Dj9l2L qCl6/Y6nJoTP4j9Fvfv2B4hYE/k26UYtbIzWs0cESXvFyK+tSwSe7VflZ72Dr3RdS/nU2ULeYuZ nTD//Y4uQJoTWkmSFEp9JLheMZw== X-Google-Smtp-Source: AGHT+IGWdo01nKOBlYwmJrYcInX0d8KeSKo4N/PiVIliZLQS8wTxPrBl3O0gvGLSKbDZOe4bjzxYPT8mb5rPvN+X+A== X-Received: from pfbfb17.prod.google.com ([2002:a05:6a00:2d91:b0:736:b19c:1478]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:6f57:b0:73d:b1ff:c758 with SMTP id d2e1a72fcca58-742a98abbecmr31372473b3a.18.1747874415752; Wed, 21 May 2025 17:40:15 -0700 (PDT) Date: Wed, 21 May 2025 17:40:14 -0700 In-Reply-To: (message from David Hildenbrand on Wed, 21 May 2025 09:48:41 +0200) Mime-Version: 1.0 Message-ID: Subject: Re: [PATCH v9 09/17] KVM: x86/mmu: Handle guest page faults for guest_memfd with shared memory From: Ackerley Tng To: David Hildenbrand Cc: tabba@google.com, kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, 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, 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, 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 05DE014000A X-Stat-Signature: 9qhfz4pk5n636nd11sbbahatsb46az6a X-Rspam-User: X-HE-Tag: 1747874416-742874 X-HE-Meta: U2FsdGVkX1+rdwjEo7fW+XFjj9BVZjE1qibSzSvf+ubu0cK07V6JDGJGL1MvLa0Nvyu7Mm1CK7lGXQlvjKPq65P043uI6Q6yptRst/XTdfg4NWiuhzT7fhoQed6ABGCrD1Elj6mOW/3FiYo4yZVV6x77/VympWudbm9GzIuSksqkKQqTdQW2Xvztt/s+rFbrua20yik5Pd+D8UTSYqnfhUx3/KMAv3bfsHw0T46Gu9HKTDy0HaY7UFAwFUkHdM4IbpbN61nKZA0HjPfnULQjhQrpD5G09lNtSnvt59N1k8InOC9UO17bJqP6e9klieIUrJdfO93nusFg8+YuZqbKnQAR5nLFpaJ8ZrpYfTCNgt+A9P9BJ7/bODN7tsJMsB3gP6F9Ji4UqEVBve75JJt07Dij0CnxijSO/OfdFqdI4e0/ekxwHBgmeYtyYVy9rObZZuNdthDEDOANwXSEGHXLEUAFX+e44UejrKj/76QsAZ/M2ANlbvUt0weAg7jnQUaSsbGlmALau7MX8TEAQXmxL1IofBzpiXSj7yZACIKwPwPS6MfdMJ2F26mEoBeEfjkw22yn8EU5IlaKsjymyiwvexvysL+c0hXawPA/8L9xY6VIB6oN3D8dbvWA7h/r3D/PSD9bDvh+dV9lksHSA2aph2ky4MdOK6fXmVav+644DWvn3vP0xnqfKRFJ8cLn7SR7/p7IunEzRDPvayvSOXl7fpOoz3U2VzXCu+dtKsUTgB58X7R7H5mEBCJsrvY65NGVXES+vWu/4kGiWpyDg3IdBlc4y77LJQ2ORF0M7HCjic8tKDVXxz2yUP0SFSp9x4gghJTPEzBPJ2qAyNiwj+IbAIDeDFj1IZenrJPOMl3HK0ayYIqnQsJemNgBebpd1MxmFkXUwPC5DEVxysWC+U66kXyMnP+o+DRKwjCsXOVZC44jKcldlX1z1aUfLYhsnB2DFSfd6rEsAIuX/SHZYbb sCYvj6sj /p6EuhDRToLh94lvA/jHCLP5R2sjoWpXq8//WNSz9kXMdxFqiG+mxMQq2wJE4phvHPqr7/Da0H8HPniEim6kngtLrfqlwV4AT28uCKfIXDa+mC30A/9Ww/JJ5LtPzIrc0lmnABNM5KEnHfiAZLgkhlZToV41GDSN76UveYKiU8uDcGWhYCSLJFShEmEb+f6sh9HAVvMslbTuCY4vLVty6F/oVptzUaKZrivrOZ9g7sBrfDskq2mX2PGcQ6zr7TmAe66uFyYDwBTEhu6N6ZIc4S7y6gKF04SofAWAKri2pPxh7ioAmgZ1uQA3b/1ZXvK8/03MsgctAz5Z+yczL0sm1hpncl4XvibVmHQvY7HZnAjoq4kmCyiDPz7Z1U4UeXqWjgBhKJqvWqmYxNFnf901N9hUKLVvtPYKPUP6c2VyUj5Lw/KmCv+xmExZYg3UaRya/C+Ia69iiUBlwGBAuCC7i5xcd9EAh53y5pxSeR+6GBLMLQCkzER/G/Po3vPjy28j+L0FWDXaSgTMLW4bjXb9dKWkVY9sNygT6r3ykNF3U0feB+qvrxuABz6c0lNlgj1th/xHDnN3R+8mtiN0qDKYxtApiGz/cI5YwsTFljXtVThjm361Y1/sGwKUF0ZSNgvK7j7LKEllNK3wZTYuOJcg3FRoXrdFnwW/WF3rWzS1xqRTdkujSadXF6k/xPd/P9Z2vU89/jcdqZyytdwc= 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: David Hildenbrand writes: > On 13.05.25 18:34, Fuad Tabba wrote: >> From: Ackerley Tng >> >> For memslots backed by guest_memfd with shared mem support, the KVM MMU >> always faults-in pages from guest_memfd, and not from the userspace_addr. >> Towards this end, this patch also introduces a new guest_memfd flag, >> GUEST_MEMFD_FLAG_SUPPORT_SHARED, which indicates that the guest_memfd >> instance supports in-place shared memory. >> >> This flag is only supported if the VM creating the guest_memfd instance >> belongs to certain types determined by architecture. Only non-CoCo VMs >> are permitted to use guest_memfd with shared mem, for now. >> >> Function names have also been updated for accuracy - >> kvm_mem_is_private() returns true only when the current private/shared >> state (in the CoCo sense) of the memory is private, and returns false if >> the current state is shared explicitly or impicitly, e.g., belongs to a >> non-CoCo VM. >> >> kvm_mmu_faultin_pfn_gmem() is updated to indicate that it can be used >> to fault in not just private memory, but more generally, from >> guest_memfd. >> >> Co-developed-by: Fuad Tabba >> Signed-off-by: Fuad Tabba >> Co-developed-by: David Hildenbrand >> Signed-off-by: David Hildenbrand >> Signed-off-by: Ackerley Tng >> --- > > > [...] > >> + >> #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES >> static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn) >> { >> @@ -2515,10 +2524,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, >> bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, >> struct kvm_gfn_range *range); >> >> +/* >> + * Returns true if the given gfn's private/shared status (in the CoCo sense) is >> + * private. >> + * >> + * A return value of false indicates that the gfn is explicitly or implicity > > s/implicity/implicitly/ > Thanks! >> + * shared (i.e., non-CoCo VMs). >> + */ >> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) >> { >> - return IS_ENABLED(CONFIG_KVM_GMEM) && >> - kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; >> + struct kvm_memory_slot *slot; >> + >> + if (!IS_ENABLED(CONFIG_KVM_GMEM)) >> + return false; >> + >> + slot = gfn_to_memslot(kvm, gfn); >> + if (kvm_slot_has_gmem(slot) && kvm_gmem_memslot_supports_shared(slot)) { >> + /* >> + * For now, memslots only support in-place shared memory if the >> + * host is allowed to mmap memory (i.e., non-Coco VMs). >> + */ > > Not accurate: there is no in-place conversion support in this series, > because there is no such itnerface. So the reason is that all memory is > shared for there VM types? > True that there's no in-place conversion yet. In this patch series, guest_memfd memslots support shared memory only for specific VM types (on x86, that would be KVM_X86_DEFAULT_VM and KVM_X86_SW_PROTECTED_VMs). How about this wording: Without conversion support, if the guest_memfd memslot supports shared memory, all memory must be used as not private (implicitly shared). >> + return false; >> + } >> + >> + return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; >> } >> #else >> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) >> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c >> index 2f499021df66..fe0245335c96 100644 >> --- a/virt/kvm/guest_memfd.c >> +++ b/virt/kvm/guest_memfd.c >> @@ -388,6 +388,23 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma) >> >> return 0; >> } >> + >> +bool kvm_gmem_memslot_supports_shared(const struct kvm_memory_slot *slot) >> +{ >> + struct file *file; >> + bool ret; >> + >> + file = kvm_gmem_get_file((struct kvm_memory_slot *)slot); >> + if (!file) >> + return false; >> + >> + ret = kvm_gmem_supports_shared(file_inode(file)); >> + >> + fput(file); >> + return ret; > > Would it make sense to cache that information in the memslot, to avoid > the get/put? > > We could simply cache when creating the memslot I guess. > When I wrote it I was assuming that to ensure correctness we should check with guest memfd, like what if someone closed the gmem file in the middle of the fault path? But I guess after the discussion at the last call, since the faulting process is long and racy, if this check passed and we go to guest memfd and the file was closed, it would just fail so I guess caching is fine. > As an alternative ... could we simple get/put when managing the memslot? What does a simple get/put mean here?