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 CFAB5C001DC for ; Mon, 31 Jul 2023 16:24:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54CBD28006D; Mon, 31 Jul 2023 12:24:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FDB06B0108; Mon, 31 Jul 2023 12:24:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3770128006D; Mon, 31 Jul 2023 12:24:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 24C126B0107 for ; Mon, 31 Jul 2023 12:24:13 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EE3EB140844 for ; Mon, 31 Jul 2023 16:24:12 +0000 (UTC) X-FDA: 81072429144.23.5DC8717 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf26.hostedemail.com (Postfix) with ESMTP id F06F8140014 for ; Mon, 31 Jul 2023 16:24:10 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Nxq6zpIl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of tabba@google.com designates 209.85.219.50 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=1690820651; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3bBibAebd9TH21iCDO05hSEk2osKPAFkgUcjQOZN6IE=; b=ukOguDsqhFvT7XbO6643uJRMD4IXSSJ0t2VRB9BdYqk3XTGOKxhGCIvP0/9bydAzSkQysG 5ve4gMeqmncXYgjlUzpC9EzTALnZr/rN0yLo7lNNOriP/koDke6mgRcRpajYVoEL1PUuss F7zQ5WMO3ZhLd6xL1d8OkMpkXVbdS/8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=Nxq6zpIl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of tabba@google.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690820651; a=rsa-sha256; cv=none; b=C+yrD4YX9rDOHHuGnIHKrL4OdgyacZkpcVP8keukX8EqWERjJ4LNyQxxmxuHKwmXHmHiaQ 7wd+BBx286tUDt3MJ7QIujxDCauOktpsRc2LpRRKyQaJvMNWGnZhjhtBtQzsB+o8NUng/z ctLsh0mCtDLHJKsjtBGa/LVvk86N8EI= Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-63d48c3d242so24965826d6.2 for ; Mon, 31 Jul 2023 09:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690820650; x=1691425450; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3bBibAebd9TH21iCDO05hSEk2osKPAFkgUcjQOZN6IE=; b=Nxq6zpIl4t0T0IKgYCttihPgWkXDGg2v82UeoDRuJEPiuoZCcaCHDZLE9kkIxiKoGj jk+IsC1Guj9oI8nO++cnUqPSWZhSmAdBVc5lsM1hT0kSe4RC/KjMhhSc6wlqkqU2YaQ2 MlzhwgMrC6YuHdeNmM0ceLnhR0bBMJIyRtICLHnduD/dx0KJOUH8SaivN46+P6VL/13o HD2+rdmaVCfzWB1fiLuejcoL89Z+FWgZTnHkXXYaDxZvnDyh2EIFMo2Vuj5jGb8JG448 0UmR6aeSUdj4a9FGESdjj1akt6y1FHupeca6JLTCIL1tXPbyPZc4VruR8nQPmlFHhYMX m2iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690820650; x=1691425450; h=content-transfer-encoding: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=3bBibAebd9TH21iCDO05hSEk2osKPAFkgUcjQOZN6IE=; b=VpLoPgS6sH313BluvYjXHUEKNmiThRiKXET59QfBXhOkWwKFQZNrpbvpvEL6x63OxV K4eKJ3DURGSumAsU/MQYKwz5VyG6z9eeN45dL0lymqxIpJvt7MC0E5xkvu6xvLDseEBg PU4pWSwPqOlAM+ydQXYrscb+/RjeIpN4L9/iwPOfBitWvBEzx4XH+paWWqH4JPPY6Qro aZA0va/q/RMauVWRL9cS97/QTqha8mmrvRERtOh96EsYhR4jYoP1HcJwHIG08iAnASUG OdKrxeDoR+67D4RAB+Yk/7xwAf6C/L+NbqAj2j0aS5u4R959hC2a0f3px5oJQHcYCoyE cDAQ== X-Gm-Message-State: ABy/qLZdMWtBHRaRih+UmtiD2Skx/f5ddbr0h8VosAXV8YF4GT8vMlkI JLoI8PWBcY2nu7qgnCazVfBFQDV/DET4DgzbsiihGg== X-Google-Smtp-Source: APBJJlHREYUxXxwX9gGy7EcKK3cJKFiEBqZ2OxDI6ULebXBrqt9zCYKQ0hqOpLlGDOWyAd0KbYFFLQMR5e4GSI0P8JE= X-Received: by 2002:a0c:ef0a:0:b0:63d:281d:d9cd with SMTP id t10-20020a0cef0a000000b0063d281dd9cdmr11195773qvr.57.1690820649949; Mon, 31 Jul 2023 09:24:09 -0700 (PDT) MIME-Version: 1.0 References: <20230718234512.1690985-1-seanjc@google.com> <20230718234512.1690985-13-seanjc@google.com> In-Reply-To: From: Fuad Tabba Date: Mon, 31 Jul 2023 17:23:33 +0100 Message-ID: Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory To: Sean Christopherson Cc: Wei W Wang , Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "kvm-riscv@lists.infradead.org" , "linux-riscv@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-security-module@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Chao Peng , Jarkko Sakkinen , Yu Zhang , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , Vlastimil Babka , David Hildenbrand , Quentin Perret , Michael Roth , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F06F8140014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: gn7btqqweyf8b83mdcbayribsyppe3s1 X-HE-Tag: 1690820650-424767 X-HE-Meta: U2FsdGVkX18R1p11YEBMOpOVSAHl0qWt64GyN01Kf0YSHbujB/hcmLVCRD8uh+hDfW4/w37mPRW6NgRVvycqwknqQrb2rgzPQp60HcmTHShypqgke4fJFObn7NI1rVk02OGqEjMLNqQx8TN0QyCle5jPsKID021f3vLzENBjNy7/DQ7lpX5gs6OF70yVEm0O4q80dtPd+9ewmezfJCUdFfc0bn+GH5pY2Oe600HRG/8UMOpqOl5gF2UkHdYWxseKxQonOREyLp4xaAYLusl0yyMqc6J/ImrYSVotmVTwZdQ5N2IpxQCyEoNsmirJNhSGg+rQWzr0wq5+aT2BHRdeIBQe09GIvmvpDF30gJHPubfwtmnkr7/iUx9fNZ7PQB4FlySw3lUHt8K5emKs4psSSw7ks1vl467eI0v28XPhKW0s3Uw9kvPYjD0Kmm43PBKlIqiqSVBgfBwG61iuJkwb25myBMa98EAt9tLLnr+J5SKhzWK6YK/aqsf3X13rd79YTAta46U/5JSpYEfjQiZQdsz45wc+KbRLd2ZjZtQJbgEX30/l1u4u8mf96aCSILpnZSSko16ueyXxDPKIDjH+wLwlMKLDjvdidDAHN7+pPvQugw/gxXmPK3robCsJNaMM8zxXQ0dwocbiMvx48uh0Q2ht25NRe3t6cFSXFzJniDk/CzQWDyzziiEPafWivbtN0i0gf8Y4Itkcp2t6/bPFWJgDpEPv5UuDiLwxjMvY2prvc/OtCH9J8tpWdfaumfjTSm9B5BTlmQ4YYtEk+Vs74J/e0k9wCYVHXXFcBmb9Q+kY4ANzEHgCPQ7K/u/DtrOthQLCantwoJhFCveguVjsuEUaroegkUSjFIcsKlKT2SBMg+sxWEbrdFM1i9zjO2sQRt1MAaac3XVRBo/W9QJkL2O5VwXRsIhUaUWrY8ifxuCQ762JLYx2KoZ6C31oF9nyKxlLOBj1/WAXV23QBQR W5PZdziH O3N20qVFSPdUi7ZDMH+lWp1PLyLBbICWDoWyUvFqQeL48zkMj624WvtljtXsQZ7EsbBjshEfNaLJIlZRV7QD+GLzwn93CjuiH32eUe6W/eTfC9gIZGfrbRVGfmRAy5t3jYHxxA16e1UgpmkBibtZB/Ct4zYYOpOigZWebGdht+K1IcjLv3S/WnTLSYqLoCyOW7OegTWFPYUL2LO8uSYUsbIjZAuGh+LRy4qIC5FYvIYV3De5L5kcrClfeLz4AIcgq4QF0G+gP4ms/N1A8q3i4aM6B35MRQx2DtOCGGvEZGpd4TktHlUyeeeX7gyO1jRi75m1JGgU+efpPKGglV5L/iTuQIDzaE1J/9S92HHzI2BvAuY3Qxw4ChX49DhBwIa3mcPOT/4EnvuuBBKkgc+BQjw6UEQ== 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: Hi Sean, On Tue, Jul 25, 2023 at 5:04=E2=80=AFPM Sean Christopherson wrote: > > On Tue, Jul 25, 2023, Wei W Wang wrote: > > On Wednesday, July 19, 2023 7:45 AM, Sean Christopherson wrote: > > > +int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot, > > > + gfn_t gfn, kvm_pfn_t *pfn, int *max_order) { > > > + pgoff_t index =3D gfn - slot->base_gfn + slot->gmem.pgoff; > > > + struct kvm_gmem *gmem; > > > + struct folio *folio; > > > + struct page *page; > > > + struct file *file; > > > + > > > + file =3D kvm_gmem_get_file(slot); > > > + if (!file) > > > + return -EFAULT; > > > + > > > + gmem =3D file->private_data; > > > + > > > + if (WARN_ON_ONCE(xa_load(&gmem->bindings, index) !=3D slot)) { > > > + fput(file); > > > + return -EIO; > > > + } > > > + > > > + folio =3D kvm_gmem_get_folio(file_inode(file), index); > > > + if (!folio) { > > > + fput(file); > > > + return -ENOMEM; > > > + } > > > + > > > + page =3D folio_file_page(folio, index); > > > + > > > + *pfn =3D page_to_pfn(page); > > > + *max_order =3D compound_order(compound_head(page)); > > > > Maybe better to check if caller provided a buffer to get the max_order: > > if (max_order) > > *max_order =3D compound_order(compound_head(page)); > > > > This is what the previous version did (restrictedmem_get_page), > > so that callers who only want to get a pfn don't need to define > > an unused "order" param. > > My preference would be to require @max_order. I can kinda sorta see why = a generic > implementation (restrictedmem) would make the param optional, but with gm= em being > KVM-internal I think it makes sense to require the param. Even if pKVM d= oesn't > _currently_ need/want the order of the backing allocation, presumably tha= t's because > hugepage support is still on the TODO list, not because pKVM fundamentall= y doesn't > need to know the order of the backing allocation. You're right that with huge pages pKVM will eventually need to know the order of the backing allocation, but there is at least one use case where it doesn't, which I ran into in the previous ports as well as this one. In pKVM (and in possibly other implementations), the host needs to access (shared) guest memory that isn't mapped. For that, I've used kvm_*_get_pfn(), only requiring the pfn, so get the page via pfn_to_page(). Although it's not that big, my preference would be for max_order to be opti= onal. Thanks! /fuad