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 EBFB2C369D9 for ; Wed, 30 Apr 2025 18:58:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B35E46B00AB; Wed, 30 Apr 2025 14:58:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC0126B00B5; Wed, 30 Apr 2025 14:58:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EA506B00B9; Wed, 30 Apr 2025 14:58:39 -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 6BB336B00AB for ; Wed, 30 Apr 2025 14:58:39 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7980E5BDBA for ; Wed, 30 Apr 2025 18:58:39 +0000 (UTC) X-FDA: 83391621558.27.BD14E5B Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf10.hostedemail.com (Postfix) with ESMTP id B8F37C000E for ; Wed, 30 Apr 2025 18:58:37 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=q8EL5CQ0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of 33HISaAsKCFMvx5zC6zJE8119916z.x97638FI-775Gvx5.9C1@flex--ackerleytng.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=33HISaAsKCFMvx5zC6zJE8119916z.x97638FI-775Gvx5.9C1@flex--ackerleytng.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746039517; a=rsa-sha256; cv=none; b=M6wMuIioWIL1fvaxzqaqaVvPa/V/5hDD2d+dJbxk6R0RjVZAhO40Q70ADDfVL9xhmWZlnC QjAQVdTM3d34B8gq14SGeL3ytwGw3KpPJVnqB8hbiqdJhoQLKVM84ziLvWS+xcPh5RHd/S Q/Vo62wuMRxajUELFT4ODFsgXVAkOEk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=q8EL5CQ0; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of 33HISaAsKCFMvx5zC6zJE8119916z.x97638FI-775Gvx5.9C1@flex--ackerleytng.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=33HISaAsKCFMvx5zC6zJE8119916z.x97638FI-775Gvx5.9C1@flex--ackerleytng.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746039517; 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=9fxPskNZofSZePK1/+4gGlwKg7DgccpEf2CnNOiWW54=; b=t8vZtE3ZO7X+NJ2qMl9kzPGszjp05mVgzAQlATVRlf+LAqZ6JelyKyk82CABn/hpkcbA88 LxdbeUzCjCYVNUVHIPRhLW4M9qSIoD1X0no8z+IRtCejeLND/ecFMPfR9hl9VCQNpwUGqB X0+XOCogS5JOmuOIluouq7H4bbSTvm4= Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-22aa75e6653so1251255ad.0 for ; Wed, 30 Apr 2025 11:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746039516; x=1746644316; 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=9fxPskNZofSZePK1/+4gGlwKg7DgccpEf2CnNOiWW54=; b=q8EL5CQ0Jc/JGJJIzrCJStykoYR1kq9DL/KZrPwqN0Xa7y5Q71G8uwqKfUXS841O5O KUWKn7KOP/xo3uaXIviJClHK1D+0eTdp2Fa7pp1ozubNY2x0YkOdD4zrMntnMalMmomB QvVKDzhjqGAozofmqKJkhiFZwnxK0i1ldVWADHqpDD0Abtk+fFW74KlCnzH7i8Cgc1XD /eb4wd8yvXi9yYqkYVJ3OiZt9Yy7U9D28fHkoUsz5APAkDpTLHTnyJ2ZQtQvkkO0wND5 P1194NL9rMpjftSWyWsjy3Z0qjv9vchT+THQmJdCx26gzYOvnwQi7N243mzXAUCPBGPh mtLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746039516; x=1746644316; 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=9fxPskNZofSZePK1/+4gGlwKg7DgccpEf2CnNOiWW54=; b=SER78lLGJAaD8Ug+97pJgPN7b0n5hnCdUoJGm5ebrjFO6mtX1a9Bt4rQrobt4GAT8I MLu4VlCydKlQoKtKdtMaA8n0kFjiaWE+teoBcMaz/gj3UmOWTtEo9N4WM87HlqdWxcod pJfIvW/rBKji7umEkkqr7YYaNvdEtaK7x6dJO0PVRxYD1xSrA671LeeieLhKVUAA1ljV /vNEK//9Dmo4vA1YzozbXfelbTzKmw+B9iqqPDmBXcwzuYyHdODM5gkb1fgx3M3yHxcr HPQWSCJ9XIYCvuybQmWsBgnYmM+6JZ7K0b2xOglEFn6BzCESfJ4foNQpaEHtS9TOrxO+ xt6A== X-Forwarded-Encrypted: i=1; AJvYcCUaEWB5GDvgR1mEz5o/rUJGzzvJQ0mHzzKR0ZDq6GFZkJvCBVDMdndKl0ozb/lg3fxvgUxa92LHvg==@kvack.org X-Gm-Message-State: AOJu0YzPsAzMHYW31B2TJ0DCNZPU8QjkIA3yMYJAmIo+6+EBJcdaT8w3 g+hcoXopYLG0uk3otc+VtXaKqmyhvMAFVDJphpcNcQaaBxNoHgrs1cbcbi5QjG1WrE2LpPFGXKe K9i4ZbJNou4JYqYRaDHUinA== X-Google-Smtp-Source: AGHT+IHodHWuK0AUHmI1CfG6FAG4mDv2udQakmxdt0HnbC2aAg1MwCYAsZE64s6Z76O6H15e9JHN6nTHctRoqbalpQ== X-Received: from plch19.prod.google.com ([2002:a17:902:f2d3:b0:227:e538:4d17]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:910:b0:223:432b:593d with SMTP id d9443c01a7336-22df3576684mr62110065ad.42.1746039516391; Wed, 30 Apr 2025 11:58:36 -0700 (PDT) Date: Wed, 30 Apr 2025 11:58:35 -0700 In-Reply-To: <20250430165655.605595-7-tabba@google.com> (message from Fuad Tabba on Wed, 30 Apr 2025 17:56:48 +0100) Mime-Version: 1.0 Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups From: Ackerley Tng To: Fuad Tabba Cc: 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, 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, tabba@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B8F37C000E X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: a7oikepgu5hy4izjsbp4zd8xsm8t89x1 X-HE-Tag: 1746039517-958220 X-HE-Meta: U2FsdGVkX19kKgyO8Ht46gmFio19AyG7NjpF664ElAksPkYCwwpmfoG/CI73/rSDurbhT9UyO955hzrRzyuYUtuGpeMU/sPGBbzoYcSW/MGLq9lIqUGnFc1j9hJ9GAPX9MUjmAosviunE4eNOl4q1eaTm2kif3mpM5pEMEiwh6MKiEZx4R6nHc+dytohHad9GiX+kCDJ3C3mMzxk95M5BsBD2L+DcDy4rvqUpp2Paf3Z+xWDVo1KxbukZUQk/Bn5aH9U08V7Y1caTi3fUe7rjNDimXLgBsVijPZ55sm/QH1X6gF5mIqkT7oH86to773NusQ1+mFcgjqFVeCSs0YF1DSXmKY6SQLD1V1WTf7i1n63BhqierQANY1xQB/ZrOqQuOXx5YSvOO1d0kh+6e19f/tRCELL2q2Xh6LJWWQqeuGzf6hyXDb3kkN3WSYFj9KfjM4p0j1HYKSctHSrc/kIN5wbxgZ3bYrwm548UFlO6VhcXZYrmZAMIpqA/C7tXw1wfTheoh9fz3LFEbicM3h7zDFdAW7M7iDX/YiqNtD6raof30M4GW4gh4ylOIzKEg9qlp0k2JSWlkTannfx+ptdDzFDrD+6267tvluX9jlhlkdgzarLQVvj3zqX3YzCbusFdZaw1Ida4WKy3MTlQihr4QNZiyHa8WM1njK+dpq+VO0vGd3P5ia7cvtm+id//6TmOwmph0qFixTkjWcHh7tdmgQFrElWnEM0NfPR6zuJ/Uuud583HowZ1YnkSrrMjSeqqcybn1UPTGv8hCy/P02ATTzsGE5ANNOjdbuGc3DnS5Y2r1w3J/AAoLKRV4Tx6sccR8Ln6q1cUka/U88hlatjoa+ErdwPjtrq3cSY/4gUXi25JGCKpW3j19decROBr2MIh2DqKAoPTK7kBvOwgXvbhQgwq9lImithKHR8zryeU/7YsYV+5KLIkA2GQg2jDXOcB1K7GxSXS9ZdYjxE8k8 SmnTvbel lU4wHYnOjcN63UqRRVq9ACvrTJc5q/9BBLcX2VTAT2IQRYKyThxYR6cibruaDXNqghITjq2L8Vhi3SWYNSCPv1Y33e0wGGgwZVLYPNdOFog3tC55mwV6kKc0Xm02T7zuLdljTohwn/4d6ODkGU4quy7KZfH6znRFqMeDeILZyJhy3IbKcgmFlDIo602lTAgvRduDodNJUFnnq+QVRBaj2e0a1tWUak56SelKpfNXaKzEXq9gHKjnUe12Ie4toHyUJedJjxhyT+hOYcke4t4t+yqVGsS+JW0nhTpOggAvyAJuFif6cKv0cfEquvFwBRmw3T7rZylwEzcX+yG6yFPqZaGfHtS+TuxzEwFFrOBf1NcP2flXaHF1kFOmsQsb2uvvUV5g0fS3O5wjw3mJRc7JkO5n4cDNRquZtSQ6RLstsc9UwfMJK9Mb0QxeTFCOppTUjW4nX9hC7cWzgm/40XnoRghDQRSYD67g9rzXXShOI7LsDUfGBAEDQuabwgYV2QaUK3HugOa1GADvr4kx+y5VzdIZUo/X4WjrADkjFGodPoRjQXxye+cTCB708gtYomf+NE6ajB2eGSuQ0WT8BL04LpHne8fHZ+thImZIW5JLVqyQbjM8/YeYmuM7b1VIDg2w5NxHj6MM0iOYFabPvtO8F08vaOnjyTKV6xjrhSHoN6/AXUqUL4dJGO3LpRUsrzn1GwYvauUzXm3yBYHw= 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: Fuad Tabba writes: > Until now, faults to private memory backed by guest_memfd are always > consumed from guest_memfd whereas faults to shared memory are consumed > from anonymous memory. Subsequent patches will allow sharing guest_memfd > backed memory in-place, and mapping it by the host. Faults to in-place > shared memory should be consumed from guest_memfd as well. > > In order to facilitate that, generalize the fault lookups. Currently, > only private memory is consumed from guest_memfd and therefore as it > stands, this patch does not change the behavior. > > Co-developed-by: David Hildenbrand > Signed-off-by: David Hildenbrand > Signed-off-by: Fuad Tabba > --- > arch/x86/kvm/mmu/mmu.c | 19 +++++++++---------- > include/linux/kvm_host.h | 6 ++++++ > 2 files changed, 15 insertions(+), 10 deletions(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index 6d5dd869c890..08eebd24a0e1 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -3258,7 +3258,7 @@ static int host_pfn_mapping_level(struct kvm *kvm, gfn_t gfn, > > static int __kvm_mmu_max_mapping_level(struct kvm *kvm, > const struct kvm_memory_slot *slot, > - gfn_t gfn, int max_level, bool is_private) > + gfn_t gfn, int max_level, bool is_gmem) > { > struct kvm_lpage_info *linfo; > int host_level; > @@ -3270,7 +3270,7 @@ static int __kvm_mmu_max_mapping_level(struct kvm *kvm, > break; > } > > - if (is_private) > + if (is_gmem) > return max_level; I think this renaming isn't quite accurate. IIUC in __kvm_mmu_max_mapping_level(), we skip considering host_pfn_mapping_level() if the gfn is private because private memory will not be mapped to userspace, so there's no need to query userspace page tables in host_pfn_mapping_level(). Renaming is_private to is_gmem in this function implies that as long as gmem is used, especially for shared pages from gmem, lpage_info will always be updated and there's no need to query userspace page tables. > > if (max_level == PG_LEVEL_4K) > @@ -3283,10 +3283,9 @@ static int __kvm_mmu_max_mapping_level(struct kvm *kvm, > int kvm_mmu_max_mapping_level(struct kvm *kvm, > const struct kvm_memory_slot *slot, gfn_t gfn) > { > - bool is_private = kvm_slot_has_gmem(slot) && > - kvm_mem_is_private(kvm, gfn); > + bool is_gmem = kvm_slot_has_gmem(slot) && kvm_mem_from_gmem(kvm, gfn); This renaming should probably be undone too. > > - return __kvm_mmu_max_mapping_level(kvm, slot, gfn, PG_LEVEL_NUM, is_private); > + return __kvm_mmu_max_mapping_level(kvm, slot, gfn, PG_LEVEL_NUM, is_gmem); > } > > void kvm_mmu_hugepage_adjust(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > @@ -4465,7 +4464,7 @@ static inline u8 kvm_max_level_for_order(int order) > return PG_LEVEL_4K; > } > > -static u8 kvm_max_private_mapping_level(struct kvm *kvm, kvm_pfn_t pfn, > +static u8 kvm_max_gmem_mapping_level(struct kvm *kvm, kvm_pfn_t pfn, > u8 max_level, int gmem_order) > { > u8 req_max_level; > @@ -4491,7 +4490,7 @@ static void kvm_mmu_finish_page_fault(struct kvm_vcpu *vcpu, > r == RET_PF_RETRY, fault->map_writable); > } > > -static int kvm_mmu_faultin_pfn_private(struct kvm_vcpu *vcpu, > +static int kvm_mmu_faultin_pfn_gmem(struct kvm_vcpu *vcpu, > struct kvm_page_fault *fault) > { > int max_order, r; > @@ -4509,8 +4508,8 @@ static int kvm_mmu_faultin_pfn_private(struct kvm_vcpu *vcpu, > } > > fault->map_writable = !(fault->slot->flags & KVM_MEM_READONLY); > - fault->max_level = kvm_max_private_mapping_level(vcpu->kvm, fault->pfn, > - fault->max_level, max_order); > + fault->max_level = kvm_max_gmem_mapping_level(vcpu->kvm, fault->pfn, > + fault->max_level, max_order); > > return RET_PF_CONTINUE; > } > @@ -4521,7 +4520,7 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu, > unsigned int foll = fault->write ? FOLL_WRITE : 0; > > if (fault->is_private) > - return kvm_mmu_faultin_pfn_private(vcpu, fault); > + return kvm_mmu_faultin_pfn_gmem(vcpu, fault); > > foll |= FOLL_NOWAIT; > fault->pfn = __kvm_faultin_pfn(fault->slot, fault->gfn, foll, > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index d9616ee6acc7..cdcd7ac091b5 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -2514,6 +2514,12 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > } > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > +static inline bool kvm_mem_from_gmem(struct kvm *kvm, gfn_t gfn) > +{ > + /* For now, only private memory gets consumed from guest_memfd. */ > + return kvm_mem_is_private(kvm, gfn); > +} Can I understand this function as "should fault from gmem"? And hence also "was faulted from gmem"? After this entire patch series, for arm64, KVM will always service stage 2 faults from gmem. Perhaps this function should retain your suggested name of kvm_mem_from_gmem() but only depend on kvm_arch_gmem_supports_shared_mem(), since this patch series doesn't update the MMU in X86. So something like this, +static inline bool kvm_mem_from_gmem(struct kvm *kvm, gfn_t gfn) +{ + return kvm_arch_gmem_supports_shared_mem(kvm); +} with the only usage in arm64. When the MMU code for X86 is updated, we could then update the above with static inline bool kvm_mem_from_gmem(struct kvm *kvm, gfn_t gfn) { - return kvm_arch_gmem_supports_shared_mem(kvm); + return kvm_arch_gmem_supports_shared_mem(kvm) || + kvm_gmem_should_always_use_gmem(gfn_to_memslot(kvm, gfn)->gmem.file) || + kvm_mem_is_private(kvm, gfn); } where kvm_gmem_should_always_use_gmem() will read a guest_memfd flag? > + > #ifdef CONFIG_KVM_GMEM > int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot, > gfn_t gfn, kvm_pfn_t *pfn, struct page **page,