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 3C6A1C54E90 for ; Thu, 22 May 2025 09:35:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B20966B0083; Thu, 22 May 2025 05:35:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAA786B0085; Thu, 22 May 2025 05:35:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 972296B0088; Thu, 22 May 2025 05:35:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 76D1F6B0083 for ; Thu, 22 May 2025 05:35:02 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 21CC6C0CB6 for ; Thu, 22 May 2025 09:35:02 +0000 (UTC) X-FDA: 83470034844.06.80B774C Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf21.hostedemail.com (Postfix) with ESMTP id 4A28E1C0002 for ; Thu, 22 May 2025 09:35:00 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WlbvbSRI; spf=pass (imf21.hostedemail.com: domain of tabba@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=tabba@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=1747906500; 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=jy79b00HYU3PgVrvLmPpXmz4H8JXcASWwXNlNoTyvAg=; b=yGKfjyTNiuDfxmO2QLt7l450SqXEPgD8BChUd610DB0LiB8y1AImhmUgGBoGbWm0DBf2rg JyCDpOQGrdloazm51zBHD7sf3eZbDnYqcOV/bvwonxgTnic7iXIBPPu+0XmISZGoWbcIGJ ciddg4fpnUH4xD/9o7oHjR6rgGQ+uo8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WlbvbSRI; spf=pass (imf21.hostedemail.com: domain of tabba@google.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747906500; a=rsa-sha256; cv=none; b=GShSzkgDyMTLF3BLU64pSWdM5m6jOfaBKsVRZv9liQnmwD+Um3iu+uRlNRJlnX1kGEqj5W bgaRLMkAohusTc9B+7HGuFn3JxPFCgVU9RvyZvVoYnDvdCR7GzPrcnYWMeUw5/oJzcz0pI hjTfbz2s4+G67jW3HlCeng4KN1ML2jM= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-47e9fea29easo2094091cf.1 for ; Thu, 22 May 2025 02:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747906499; x=1748511299; 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=jy79b00HYU3PgVrvLmPpXmz4H8JXcASWwXNlNoTyvAg=; b=WlbvbSRIRulB/2aLvVWBGOO1sZmF46ujg4RjYYESPYtx8H0icvbEutvKjJUEQwHabu UvbufFII8+Z1BCPu2zK/TYRvF9qGnNONQXsiK8TEu+1n0xRZ9cNn50qCvxnu6TDuKxZK oWFC+MNEqoSvRbq+pOWD1OvXmemC8ZZgJoY+qKIwxfg2J/iEbXvftrYgC9esi8flR66I +BsqCiyS/PzG4hxKyjsihxj9RxmzsYU+7UWwAaWSaUh7F8zhiWwhKCRFwrt9i5nbi5h4 Wf3+NEY3Kdhms7uMrTI+BNe+9ictP35/5dL8zlReIjgRPnhA4w457BRExQW26MCZ0vbK p+xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747906499; x=1748511299; 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=jy79b00HYU3PgVrvLmPpXmz4H8JXcASWwXNlNoTyvAg=; b=Jow1lBRDGMeFzrfFUIkI9gTJOxfM6vbp2bZOoGkiR/QEaHiYLy+EJKhtZqYoChKSwm kZkDCqRZBn8Fyxg1B6r60ug4wpCmf96s2bcFXF/zfq4ibpqYZUQQLJ3M9cGpE8Ljo/O0 BVwdek0ql+4Ml+6yTAmbS+tjyt4zQlaCxJQqhYcoixIUqb/TZQ2sLPchFU6pVqR9juUe YkOEEIX9TWQsp0xryw877ZXlhD8Aq/uqWG1AOr5ul6iNs8QfrDJbJP9u4pXFrX+iiOp2 mj4/ZC+IKR+3nbZgkfQyv+125Vo+b6dlopQFJ5/8ZZnU9751GICSGzu1Hhb3Eyp88wRp rdjw== X-Forwarded-Encrypted: i=1; AJvYcCU5ipJcPtA2zAGd/AyCiBHdtXl1tHxj2Yp1GYweHaPTWWKrPOVYVR71yuaZzx0RLw/rXISTR6ykKA==@kvack.org X-Gm-Message-State: AOJu0Yy350TLYwroostFgb7KO/m66ZRvaYYry2Z8KEQUO2+cS8eIGgfx RJ/KrwMpp2vhXMALl5cctYJFKqyDguvwDfalbg32+0ONk/pk9stAtQAUnAk2zEK6Qj5PHNAFTYF UDj/JpvGAEAZf67S73Zyrg9xM1glGJ4c20U4ukHSXTUu5dM/Id0xRWXkrhOg= X-Gm-Gg: ASbGncuK7/rtN70mZG8VOqqPtD5pAV+1z2Ed8RrxuGtg+itjy4FRo/dE5mk8WvCTcgg dmhjjrkkwlIFeZy75vc46FVQN0Qv/deedMO8XmP5Jz8JSo3eky8ikHOZx/lCkRMUJW1gar7yMK6 gvBikBx7x3HoMjTUCXtCjYlulW5rNQAq2XXs1PWDdyO0NeVVCOO0l9Ig== X-Google-Smtp-Source: AGHT+IHkrB0CTaEIuNQ7Dtb6ZGwkgF2U8LyJwoedpdOy6ZMdbF4DAs4s8wGA3z/M3baeoC2jvhF3ZXjjXGuLzYaFc0U= X-Received: by 2002:a05:622a:1491:b0:494:763e:d971 with SMTP id d75a77b69052e-49cf199560emr2054371cf.23.1747906499041; Thu, 22 May 2025 02:34:59 -0700 (PDT) MIME-Version: 1.0 References: <20250513163438.3942405-1-tabba@google.com> <20250513163438.3942405-11-tabba@google.com> <5ace54d1-800b-4122-8c05-041aa0ee12a1@redhat.com> <396dce13-dd72-4efc-9b8e-5b19c1b06386@redhat.com> In-Reply-To: <396dce13-dd72-4efc-9b8e-5b19c1b06386@redhat.com> From: Fuad Tabba Date: Thu, 22 May 2025 10:34:22 +0100 X-Gm-Features: AX0GCFtiRA83JePbGS8oYvnrZc8qR-vDopez1aCFD727cyCPFwE77yoD1LOwOUo Message-ID: Subject: Re: [PATCH v9 10/17] KVM: x86: Compute max_mapping_level with input from guest_memfd To: David Hildenbrand 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, ackerleytng@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: rspam12 X-Rspamd-Queue-Id: 4A28E1C0002 X-Stat-Signature: 8e33uhhgcfgrqeibt93coz38ayxkspmu X-Rspam-User: X-HE-Tag: 1747906500-83392 X-HE-Meta: U2FsdGVkX18pyKRLqWLMjnrBqHHBPx6hUWu65FbEdMvn/Ys6/ZGs+tzoTRCZm9l0wpYJRPj4mRXkL4sP5ROvwWLJpgqIVmajF5+gAK7ZHc8/AZLpueW0+nIDUfSIRbsbl2ORkuds6to3bVkI5ZkAlJcvbPs7HybXohRGIHVq6j/4kk/bQwY/9T3+SUXtU1f9U+VuJ4eStKZpreOtOb1z0FmA6levFLeqdM3sRRy03x7ZMsSm0gXbPz+Cxaz0EQwn0z3heE/KQtGhEPLDpHRTMjdqKZMa+WurhRfCdpmyBRMsDAStEUW/iwPk3qpdjSzuygVgwaFOr22pP5KN6GbO5uv03gJjim+fiNo8RFpzp2UPrlq8qhPkzkJ7CxFbyZlnyNiqQ/Kll9I+woaHDyDiFfB65gV7QV0NII4DOIf4kbTnaDTTraa3oytJxSSzeCGO3Gcm1k58jJEyJ/tcjjbJxCnBW3SPPTFY3LJCDy59BO8PeIkRwTMxYQAnVazByDxm4B9DeVgiaxGXf/VZbyzMp3g3fYbiH1ukQ6bmSwwRjfD2CMKsg8pqxnIGq28k4t+P+KCY+lWeudTn6/hkwNeexbX8/RCLRQkZDddZ25e0shXKxMmyv8TNqPNRRE4vBAWHP73yZfGV7miLCIb4yr/SBkyTBIb/RIYrP3+GYXI4j6LhkQ9FOJtJPfYQX6s813xAPkAIkW6uY70BZPLyxOggPWrHbZT7zHIsPtQV0xCD7ghfNSGGgZwQdIBKysvdzfCLvhGl9xQ8fZ6eFbAQzVjCKNa9vf0dTPkj5wVev0E6wfQbNVxMPwDGMIB8enNHcR3TeDUd/RP9zNCbdQkAFQqIqMmnWhelfVT8+7YjUqepi4SZgXvZrXi8GI2xDReXHZ/200x8UVzQsNpQQdnRVuOsDWoLVnYoUH1SD4wc8PMgI/0xm/Kw70IrRxResKn34FvxdCDjZqXH2A/hUE+Ro9o c5rMH2VI pZDAOFopJy9rDxvkJ/fXf9S0NAg2mnjZZVyhxFkm8eej8xysJrXBGuuEUb1aaBQzSdrJ4iRhO7tIqLxELTFEool2bnYqzAZFkK3sJPQr3tJk+mMfbEOlVtUbAabixIqJvL8OMlkSF/39tiaxcKIsC5NwFwpZrjJKlklFU9kEt4oe0omqcHFqHWxdT+86W/vknmQAnS5IKNYyeaQeurqAUDnHLC1VGR7jlSAK7C8YmfogYpYkxfubW8HHyBTXOq/b1VUYbSCiQ2sZ41un7o/Ps+xtKOeLPBMixTAAkgQ+s7nmvAXiHgCtqHtzV0KTxzUeKbHCvtjdC3SHxh9tPi9QRzmuMvWtM2dNHU6qHyfauR2iz1+s= 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, 22 May 2025 at 09:56, David Hildenbrand wrote: > > On 22.05.25 09:22, Fuad Tabba wrote: > > Hi David, > > > > On Wed, 21 May 2025 at 09:01, David Hildenbrand wrote: > >> > >> On 13.05.25 18:34, Fuad Tabba wrote: > >>> From: Ackerley Tng > >>> > >>> This patch adds kvm_gmem_max_mapping_level(), which always returns > >>> PG_LEVEL_4K since guest_memfd only supports 4K pages for now. > >>> > >>> When guest_memfd supports shared memory, max_mapping_level (especially > >>> when recovering huge pages - see call to __kvm_mmu_max_mapping_level() > >>> from recover_huge_pages_range()) should take input from > >>> guest_memfd. > >>> > >>> Input from guest_memfd should be taken in these cases: > >>> > >>> + if the memslot supports shared memory (guest_memfd is used for > >>> shared memory, or in future both shared and private memory) or > >>> + if the memslot is only used for private memory and that gfn is > >>> private. > >>> > >>> If the memslot doesn't use guest_memfd, figure out the > >>> max_mapping_level using the host page tables like before. > >>> > >>> This patch also refactors and inlines the other call to > >>> __kvm_mmu_max_mapping_level(). > >>> > >>> In kvm_mmu_hugepage_adjust(), guest_memfd's input is already > >>> provided (if applicable) in fault->max_level. Hence, there is no need > >>> to query guest_memfd. > >>> > >>> lpage_info is queried like before, and then if the fault is not from > >>> guest_memfd, adjust fault->req_level based on input from host page > >>> tables. > >>> > >>> Signed-off-by: Ackerley Tng > >>> Signed-off-by: Fuad Tabba > >>> --- > >>> arch/x86/kvm/mmu/mmu.c | 92 ++++++++++++++++++++++++++-------------- > >>> include/linux/kvm_host.h | 7 +++ > >>> virt/kvm/guest_memfd.c | 12 ++++++ > >>> 3 files changed, 79 insertions(+), 32 deletions(-) > >>> > >>> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > >>> index cfbb471f7c70..9e0bc8114859 100644 > >>> --- a/arch/x86/kvm/mmu/mmu.c > >>> +++ b/arch/x86/kvm/mmu/mmu.c > >>> @@ -3256,12 +3256,11 @@ static int host_pfn_mapping_level(struct kvm *kvm, gfn_t gfn, > >>> return level; > >>> } > >> [...] > >> > >>> static u8 kvm_max_level_for_fault_and_order(struct kvm *kvm, > >>> struct kvm_page_fault *fault, > >>> int order) > >>> @@ -4523,7 +4551,7 @@ static int __kvm_mmu_faultin_pfn(struct kvm_vcpu *vcpu, > >>> { > >>> unsigned int foll = fault->write ? FOLL_WRITE : 0; > >>> > >>> - if (fault->is_private || kvm_gmem_memslot_supports_shared(fault->slot)) > >>> + if (fault_from_gmem(fault)) > >> > >> Should this change rather have been done in the previous patch? > >> > >> (then only adjust fault_from_gmem() in this function as required) > >> > >>> return kvm_mmu_faultin_pfn_gmem(vcpu, fault); > >>> > >>> foll |= FOLL_NOWAIT; > >>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > >>> index de7b46ee1762..f9bb025327c3 100644 > >>> --- a/include/linux/kvm_host.h > >>> +++ b/include/linux/kvm_host.h > >>> @@ -2560,6 +2560,7 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > >>> int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot, > >>> gfn_t gfn, kvm_pfn_t *pfn, struct page **page, > >>> int *max_order); > >>> +int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot, gfn_t gfn); > >>> #else > >>> static inline int kvm_gmem_get_pfn(struct kvm *kvm, > >>> struct kvm_memory_slot *slot, gfn_t gfn, > >>> @@ -2569,6 +2570,12 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, > >>> KVM_BUG_ON(1, kvm); > >>> return -EIO; > >>> } > >>> +static inline int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot, > >>> + gfn_t gfn) > >> > >> Probably should indent with two tabs here. > > > > (I'm fixing the patch before respinning, hence it's me asking) > > > > Not sure I understand. Indentation here matches the same style as that > > for kvm_gmem_get_pfn() right above it in the alignment of the > > parameters, i.e., the parameter `gfn_t gfn` is aligned with the > > parameter `const struct kvm_memory_slot *slot` (four tabs and a > > space). > > Yeah, that way of indenting is rather bad practice. Especially for new > code we're adding or when we touch existing code, we should just use two > tabs. > > That way, we can fit more stuff into a single line, and when doing > simple changes, such as renaming the function or changing the return > type, we won't have to touch all the parameters. > > Maybe KVM has its own rules on that ... that's why I said "probably" :) :) I see, although I agree with you, I'd rather that indentation be consistent within the same file. Thanks, /fuad > -- > Cheers, > > David / dhildenb >