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 307D7C3ABAC for ; Fri, 2 May 2025 22:00:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C92E6B008C; Fri, 2 May 2025 18:00:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 753576B0092; Fri, 2 May 2025 18:00:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EFE46B0093; Fri, 2 May 2025 18:00:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 407846B008C for ; Fri, 2 May 2025 18:00:49 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0B4701CB14F for ; Fri, 2 May 2025 22:00:51 +0000 (UTC) X-FDA: 83399338302.18.E327E42 Received: from mail-pf1-f201.google.com (mail-pf1-f201.google.com [209.85.210.201]) by imf08.hostedemail.com (Postfix) with ESMTP id 1B3F5160005 for ; Fri, 2 May 2025 22:00:48 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=X1oDeFsZ; spf=pass (imf08.hostedemail.com: domain of 3i0AVaAsKCKgIKSMZTMgbVOOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3i0AVaAsKCKgIKSMZTMgbVOOWWOTM.KWUTQVcf-UUSdIKS.WZO@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=1746223249; 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=HzIpA2PqUi+h9odYuZwRcfgQ93IrxS3bp714MmGR4QY=; b=FWyJK/PgoT3aKf+661qzEs5VpENJN9qN6+P6oJZu8v28wBZ6XR4xwKAdFujWyqgjzxJyfM e7gSMKKJnslBt5Qs6S+8xvYbbG9hnAVkKTJzVoDVBvsouIeQWSi9j+aYyDFy908LBZgN6K fcAmWt+Tvt6cYpC7XbaWJ6Ge7fgCQOE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=X1oDeFsZ; spf=pass (imf08.hostedemail.com: domain of 3i0AVaAsKCKgIKSMZTMgbVOOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--ackerleytng.bounces.google.com designates 209.85.210.201 as permitted sender) smtp.mailfrom=3i0AVaAsKCKgIKSMZTMgbVOOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746223249; a=rsa-sha256; cv=none; b=EzgpOElHz+44wIRCUEsZEN1wieneJwoOKxhHyrkCVlGp2b43pRoxcAlfyQG8+bcLzGsdvL wxlzzCsTkjhunQQ+V3WwfM+XocCmA4uzBppnDTqUF4k5XN+W/yTRJH1LLeuAbMmllkSthb LG6WVYD59tTsAzg7T6wlpZXySkMrUzA= Received: by mail-pf1-f201.google.com with SMTP id d2e1a72fcca58-736abba8c5cso3688111b3a.2 for ; Fri, 02 May 2025 15:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746223244; x=1746828044; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=HzIpA2PqUi+h9odYuZwRcfgQ93IrxS3bp714MmGR4QY=; b=X1oDeFsZm1Ka7ulFRxO1Qxo75cCt0sKnLV8Hif4ecYyRoW9dzKb8apioM1Oqplxv8V T4vFU7Y39sCnz+Ufv5bE1cF1VV4IGyu3HCDd+6f/0yaVhb9j3WUp419BlU3H09pfVnxw zRbtOQ5wjFREy0la3gG7000ONlgUtwVbxrk0rBViy03XsLaHIlAWO7usSchr7MLvkB82 vjoE9fz1FJ+PZHFkkjfn1GU1lsjdf2PGBJSKPjctZqoX90WHM2fCfQ/2CL0eSZ+fkGyR GzxztVfw1K7Lfaa//A3kqLjDeAPok+41YnDTiGQZcsDkT+xVNa3Yza92h7/ASAVlNsn/ YWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746223244; x=1746828044; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HzIpA2PqUi+h9odYuZwRcfgQ93IrxS3bp714MmGR4QY=; b=liYHoQLuOVWJR7yiiFyPftQPWIaMHhuqEr6GRR69daClViiDTA3KCXtbNcL2bJF4Q6 0ZKMUWz4ni0UxQiel02ac8FNB7PDjkFlB4BBrC7rLGARZYuHBPVCxX0lQeYKzd6XTGpg ib/9bGB9B1iSsLgTQgWG12/nWSwV8gzp/8NGA36v9lBGc4Qxdnbx0zk5J1bYxP62FYb6 IXmCvbb6EVUSPcP9hoR31nU1q2Tboh1yYWzkqGWs0J8MJDPf2K12uwUFdQ8yMxunswov 2jb8H08rnLN2663dlJhheeBvFiqCgGoZg8YpK5Vlgm+R4YrbFORHyzu33lEjV/VB+/nK psOQ== X-Forwarded-Encrypted: i=1; AJvYcCUJRjo44hu4iOITZDs2Uz9u0Pa8PbSn1gexb7ntjdUEHw0cGo+nO+6G+WGBHkbdr82JtAwRra7Sfg==@kvack.org X-Gm-Message-State: AOJu0Yxre5CqkZtutew9hLDEBf4jw4ke86HIrM/RIU6ItAunqO3K4rzv 4gUL6nUkJsVSour6XEhp0BMN8U3Q2MMZxvud6UxUC8h8mOIFu3Zb/UKJeUFPICs0S0FTk23+9b9 HCb/Nv5QNylPeLFY9woYRYg== X-Google-Smtp-Source: AGHT+IFSm9UI8h4adWB/rZlWKofmvs0q5MWCFjV1/dpvUGE+PVue1wW4QNCfuK053lnPHObvkkKaN2wVI4yOL0c9QQ== X-Received: from pfbfn24.prod.google.com ([2002:a05:6a00:2fd8:b0:736:6fb6:7fc]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:d707:b0:1f5:8c86:5e2f with SMTP id adf61e73a8af0-20ce03edc68mr7472276637.37.1746223243683; Fri, 02 May 2025 15:00:43 -0700 (PDT) Date: Fri, 02 May 2025 15:00:41 -0700 In-Reply-To: Mime-Version: 1.0 References: <386c1169-8292-43d1-846b-c50cbdc1bc65@redhat.com> Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups From: Ackerley Tng To: Sean Christopherson , David Hildenbrand Cc: Fuad Tabba , 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, 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 Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: dk1kthcn176ye5xszc9s4ntu11j3uz9e X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1B3F5160005 X-Rspam-User: X-HE-Tag: 1746223248-20710 X-HE-Meta: U2FsdGVkX1+LQOoK9jzCfDEbNgD0YeY0rrL40SGVMlbkhUtUCEnmENjDhVf63Wb5e5fhqnF2bP5BmKr5vEcq/hm3vOrqdvlLnckU2XfafrCAKDX91R39qe+Zw+2gaZzzY8pKs94spzxliBWHvzKiHTGUXHJ9ejhgxTcZYKNJmvrpwY9yHbkZs7ujPVXSN6YOomJxDDxc0fGYn7C+luJE2qK3PVaQOzxm+M/QHiu49tWS9fBOTV2oNUZrP3IXVa4mf2KzFKwL86vSR1Qp/kcqmiY7fqQovw44BPAWllli12vXAC55sNXNf92pmmltY0/VjHeXRWz24A5gpuEQz8vdam09H4BwI2AZtODlvDyxxRyWS+eaH7ospTOsaY3L9By+mQo+RRXTn6xg74l6UH6Pz1FhPGQeEyq3LZKOXmRJYpAL3iPIys1WCO7OFgWGevmPAk69d+/eTRi+f9SeqZFjGDB/VgL3XVe5mjgMSOVAgT4UBzVRZkQepPdHeRhlU/6L4vtA4lDyTShjcjj2PF4a327eV8/xxBL5/YIUD56ChjAKLqdpvf26PAaZ4DYNt4H2NGoOw6yV8DthAHrQvsqWEOoldVTBpv/P4/wjC+WbRZGsDpxY9AUGqjrCFQo+fyO4kOBiOiP7p305SiAESyLaBE4za9+g5iSlNCj6McFVUEba4zfic6iPrXCvEqtfKG4XZtvEtLJXYEcEbU54NqAJLggxdpT38ksOlY64sNzJ4H6aicE9kC/DwLdKf91rqd/SLerxh8FTsfZavsgb4doIdykQiz9Tyc/m94RxQbTtSJmnh45afgGr6ycLTxwcFfydka+W1XIRKIabFhEAvXre7A21kbZu2+KfkjYjIFTUIxelLaJrDqZO6q9zIZDkNS9ArDm9aJzbwP5rHk18TLGeTFTLcDpgWsR6vOdbYw+HSsARgLssOfCJ9gqqN4qqDx9Tujw72TfkgennSooYu4P FyNqy476 Hpuk57MEFyvimP0o9bN4JPCO4TmD+qzNuv7phbHh+2WMIRyQmx0DwdVcqgPKbFxjKcYq6QegRWZpB5koUFotuAQakEEZ5et5S77Txj5ONLKYxmfyuBvxhmMhz+/OS/7U//D+A2mzuKTwDZ6Qmt2aO0OOxwLc02s5VJUWV74uz+ersDNkWO+FeSTquUEMqFm3ehF+YRH//54YYDbqit6AsotGF+/rqXqRnIFEhKfmCbcOWPfbQwa1wbTKvFYoOVtC1O233+cKIrE/GMPgEkQtQADYD6j+zqytlSMkjUvYsw87ZG4M+fXnjLiy4unpQqUEIH8BQ8Yer5QWpsaaG8reJn8RN5E4Iav6ixKIokVzo5L/zYkBGaEMOI6iZRU1zcglm2/vJWEuZrOnHi49uc42fs2gitB333UPE1b48E9+JBmpQdSsRaADSwr6srK1Hnzlaut2J4Rp64fY58R5vihrABcOfCjfUitaEs1J+fb4dDcrS4PsWM6mLCIaDLfO/miY1pAMGLzIFCOYScMmjWvj2gbLp8hpynJRA512qFeJwFa8aWh6iCBikKfUsLizqP/J6P5CQ6UQC5miGPHfSPilsQm3D4QBeGEoSUu4cDqnyQEphXSJaXbWyaA6RQDeG+XnUPrfYLhphCuHcyX/r/n/dUmC1XaobRwrL0d5mcgC+awCYLEvlTdjHFIEatg== 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: Sean Christopherson writes: > On Fri, May 02, 2025, David Hildenbrand wrote: >> On 30.04.25 20:58, Ackerley Tng wrote: >> > > - if (is_private) >> > > + if (is_gmem) >> > > return max_level; >> > >> > I think this renaming isn't quite accurate. >> >> After our discussion yesterday, does that still hold true? > > No. > >> > 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(). >> >> I think the reason was that: for private we won't be walking the user space >> pages tables. >> >> Once guest_memfd is also responsible for the shared part, why should this >> here still be private-only, and why should we consider querying a user space >> mapping that might not even exist? > > +1, one of the big selling points for guest_memfd beyond CoCo is that it provides > guest-first memory. It is very explicitly an intended feature that the guest > mappings KVM creates can be a superset of the host userspace mappings. E.g. the > guest can use larger page sizes, have RW while the host has RO, etc. Do you mean that __kvm_mmu_max_mapping_level() should, in addition to the parameter renaming from is_private to is_gmem, do something like if (is_gmem) return kvm_gmem_get_max_mapping_level(slot, gfn); and basically defer to gmem as long as gmem should be used for this gfn? There is another call to __kvm_mmu_max_mapping_level() via kvm_mmu_max_mapping_level() beginning from recover_huge_pages_range(), and IIUC that doesn't go through guest_memfd. Hence, unlike the call to __kvm_mmu_max_mapping_level() from the KVM x86 MMU fault path, guest_memfd didn't get a chance to provide its input in the form of returning max_order from kvm_gmem_get_pfn().