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 C9876C3ABC0 for ; Mon, 5 May 2025 22:57:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E01F66B0089; Mon, 5 May 2025 18:57:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8A216B008A; Mon, 5 May 2025 18:57:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C01E06B0095; Mon, 5 May 2025 18:57:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9CEFE6B0089 for ; Mon, 5 May 2025 18:57:14 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 993EA140C5B for ; Mon, 5 May 2025 22:57:16 +0000 (UTC) X-FDA: 83410366872.03.C6ADD6D Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) by imf07.hostedemail.com (Postfix) with ESMTP id CB3DB40011 for ; Mon, 5 May 2025 22:57:14 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qOebWK5r; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3SUIZaAYKCHoqcYlhaemmejc.amkjglsv-kkitYai.mpe@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3SUIZaAYKCHoqcYlhaemmejc.amkjglsv-kkitYai.mpe@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746485834; a=rsa-sha256; cv=none; b=v6Mk46uLnLkEPSmq0snKkSmcvgmEdi/r8AsUHbJys+bi2nvrDzwkERLr0f6k6LF7k8eUzV VMUyHSGQBmiFPUZPEQ0e9VBsfNeohqrKYdhmS8nmosqURDlrOM9M46KkstxzqIxZub8o6A nu3FZ+0D838ocp8gbz6Nz6xDeGetuf0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746485834; 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=0BvGs6Zljio1m1AEARRCFv5fDztVSWreYYxAG+gby+0=; b=p2ABYrjbdw+8RtkyWCatDNS2HVEdainzr9Tz6bW2ngRs9m0brz89rFlqksPMWdg5e0OdCB t8ca8GXncZa9i4hcucaOcMfxTHuR+Zax5Mgs26vQRqBAsA54SjWHLFsORbu8gUfxae8Qax MBIiiGBAIQIytcxqPRB9Ppbt0KdEp24= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qOebWK5r; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of 3SUIZaAYKCHoqcYlhaemmejc.amkjglsv-kkitYai.mpe@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3SUIZaAYKCHoqcYlhaemmejc.amkjglsv-kkitYai.mpe@flex--seanjc.bounces.google.com Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b048d1abbbfso4788324a12.0 for ; Mon, 05 May 2025 15:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746485833; x=1747090633; 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=0BvGs6Zljio1m1AEARRCFv5fDztVSWreYYxAG+gby+0=; b=qOebWK5rJKZtxNZOVBzC6MhhJchHLVQ/pYYGY3bJvATd8exVgHEPx+G0rZj5a9yU90 kB7u+/z1gTmrSDp4dzJTdUeqgg/FAD3bsfnFcI7KJpws5KN+sxOOEHQh4yaogublsXbi 7g9Em1Y4xwV61Z/PGrxWWWrpuqCIeWV722NaBynXpWJCoa6fLwFGo3vHXFzOXjt6Q2qP teDOQBeKw6jZ/oiMkeMdLibt0N9FP3/+hgPkppJUFOz7b2PpSo/sOrNof6A4wEo9hOBD hBXGrGj3g5YKHUWcmNi3HDhozhwTPlncJ9xB6JjEBpED8ZGARfZNepV+VEYpm326VtQm LmuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746485834; x=1747090634; 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=0BvGs6Zljio1m1AEARRCFv5fDztVSWreYYxAG+gby+0=; b=rDnlXPis19StNnHjOykQUUbOzV9uA257M4TdZaaPs2TA29ObeVdPIJw9C2BzYouwEQ 83SpA1SFxF6qvKbAnB3aTFm9MKAsdO0Ff6ZoS65gx8rZd8lxw50z+EOG6Fpb6/6I9hqZ XsmKM9Ex0WsKuj0dZvW6x+CR3wMvRW4qXKLwfH+gpaoMoMavFSvlmoLtfA6hg2JuMt1P aPrmLHJKvj2bGdSsnxMvN6tfP5XR5BvlbCWRx7GLAwxcLLTAO9putla/GUjmy6XMQtBy No5cl50jdKjdMdlRwIKpVwjPW5ThQTZpmXIg8N4wS8pr7C6Pnymx2h8I6kqT6pdYEBMf 6DwQ== X-Forwarded-Encrypted: i=1; AJvYcCVtdemSXwomBEJXTRqMHJuAllbPGETGQ5mlxWTUYVLGnG6YkVIc51GE7HfAHfsP+UvO0RbsCsg1Jg==@kvack.org X-Gm-Message-State: AOJu0YxwqkttIDr1xIt44U4k0kBzqp5nG4T9oaJ63JcutcFVBFs3C6y2 kCdDDTjGQAiRkyXJMrZR2VqVvyUvCsIkzDT84obTKTsEnixqdKKdel604u0t3JZtcn1b+rUTtPQ Fvg== X-Google-Smtp-Source: AGHT+IGr7ZwivQiQOxhRvxPnJjHbjFHUYcVKGtfq9EuMJ1XumzNpx+xuBru0RIy3XMb3f8Vooa9e9l/QbF0= X-Received: from plbz12.prod.google.com ([2002:a17:902:ee0c:b0:22e:345d:be56]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:2408:b0:223:37ec:63d5 with SMTP id d9443c01a7336-22e32ba8292mr19044325ad.28.1746485833625; Mon, 05 May 2025 15:57:13 -0700 (PDT) Date: Mon, 5 May 2025 15:57:12 -0700 In-Reply-To: <7e32aabe-c170-4cfc-99aa-f257d2a69364@redhat.com> Mime-Version: 1.0 References: <386c1169-8292-43d1-846b-c50cbdc1bc65@redhat.com> <7e32aabe-c170-4cfc-99aa-f257d2a69364@redhat.com> Message-ID: Subject: Re: [PATCH v8 06/13] KVM: x86: Generalize private fault lookups to guest_memfd fault lookups From: Sean Christopherson To: David Hildenbrand Cc: Ackerley Tng , 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="us-ascii" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CB3DB40011 X-Stat-Signature: szqesos7misyyjeucuue5r4kgrbpw8nx X-Rspam-User: X-HE-Tag: 1746485834-961981 X-HE-Meta: U2FsdGVkX1+DwbJBVfiElIIT2kaTbH6GgQv+c4nI6TYXyT+OxeJhaROBrcNddPAN86c5eCsH6z6928j5cW3TdPxXiTA25GBLEsEbjBEb0G2BCegY1FW+oP7xigPn7mYAiRs/grDcRJozv+kxypqGDNlCTxSKXQ36wa7N2RMq70e3SY4Z/4WNjbPnk1gFX/JML631k/Ds7Pq3kM+5dPyScVoNCQ0AmF9TR3gLd5Mb4WyM2tMHrAH2LTceIPLLAlRPadocBU+1Cpoy4TxEL34WNa5wPffdF/u4ES1pn8huzF/42Pm8ttdqHhCyklBWnKkMRkIv1iIVT0YVuvzo3Nbf8ZvQz5Xa7fHv8rF8jqXHnbGXuAivemnBZAJYAYKNxNahC8sa0HMxHHvw/+noj/DHDivfE+DX+vj8zsSCx6n4M13fsQDQ+/OS6Uqp1eJxbDkOLs8JFWF7l90IXjBw7Y3cWaavrxRHHXWUMGYrrtkP818WEJuYiWFa4npH4nhF67OJkNCroVpYJMNNxuiKsvsx4bvwjMjy00Lu+HvNNqqygJDmqb06ghKD3kKEVPwr0+mI5xhwXuNoTZHc5vuOhgOqOxD5Kss0c1YouyYs+ccmU7Ovnpw231ekjNUlFOBRWKi7tA9SqbEbSjWsGIgvQ8IY5rBcP+bnkwsSfbn5pSlQjScVL8uAH8Xp5O07P/HRcWdKduqWa5PFXBsVSjIqrL/x42ApslikG7s3OHi4FwUn7g844tVO9RRjnh1b7wH6zNWSr3s/a/KL64ZU8eeKLjcw5M+YTZY+U0KVeggTK9YCEL/9gRl+orNzxnDZhXysPTgnwdk63R1G4/q80LNP9ZrNFNKtqhvEy74UC1Z1bKAnYIctL43cJoba1KWE5rJ4MxKKg4jJUDlVxFVhHB419PsY+0HSz/qicYT9xK3745XFO2yGPru/By3lpkWiFoj2cQPhOIZXUK9kOycmrm+Uu1n kRve0bIb HuCBctFInrVxEXb9TSmDw8ifso4hYciTemmZFjqjgU/tCytdsR8dUFRdWVdMIjOGH5POz3FRrz9t7j/xCUgfJRPL9xvGAwdA3tPkXVwsa7/sSz1omL+FtBcT7ub6lv/iLOIKGpYXmt9rJexDV3qsuOnZGA8HHW9hVCyNcV7CPCY5JoqG7e3IXY87xtTJ/LKBsy6RwQQumY6n0Mrao2Lxf4wnE1ajN5ESJG9Df0TgMHulk2TbbMeZBb5h/EkBTDhQXxlRNSH5qx2tdtbiKDIFPr9T3cMvss3ItQDqKEtNeG+CcFZLcidEfHQDSBm+H+vsfUHhwHruJsjqgd6p8Z/7WHR9c+mtSQP7fukmoac5ETmaEavMDS5qSdljXo8TVU/08krs2rjVvEninRfZvHeGXp3HaDMtZeAMvomy7McVpFwcHuak3aOpNAaOa1HwQTOLy8PDp4xRaXd/mRdUsWuSn+OqfwmFpWs7DGOD88B2xJkIeEnA+psjdVoBHYaxStBN9e0kSDpjLYineqNHOwLTMFCY8px6kgelK+Sd6RBvP5ys3oUnWgdJZtAUpnsWoXTKNPcK0XOgyj/+BTwADqpUo6rHdfbUoj8FOlGEoXsUs0j8kOV5XeUgeDLdNE17m0kAYdUw7qG8LLeNkQMQ0iOfIvrhSG2pyvhu/QwZE696bpjsi5I0FBbJFNIahREwksgpoSURSdXsEe+ifi0tZQEKM6qn8ow== 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 Mon, May 05, 2025, David Hildenbrand wrote: > On 03.05.25 00:00, Ackerley Tng wrote: > > 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); No, kvm_gmem_get_pfn() already provides the maximum allowed order, we "just" need to update that to constrain the max order based on shared vs. private. E.g. from the original guest_memfd hugepage support[*] (which never landed), to take care of the pgoff not being properly aligned to the memslot. + /* + * The folio can be mapped with a hugepage if and only if the folio is + * fully contained by the range the memslot is bound to. Note, the + * caller is responsible for handling gfn alignment, this only deals + * with the file binding. + */ + huge_index = ALIGN(index, 1ull << *max_order); + if (huge_index < ALIGN(slot->gmem.pgoff, 1ull << *max_order) || + huge_index + (1ull << *max_order) > slot->gmem.pgoff + slot->npages) *max_order = 0; [*] https://lore.kernel.org/all/20231027182217.3615211-18-seanjc@google.com > I assume you mean, not looking at lpage_info at all? > > I have limited understanding what lpage_info is or what it does. I believe > all it adds is a mechanism to *disable* large page mappings. Correct. It's a bit of a catch-all that's used by a variety of KVM x86 features to disable hugepages. > We want to disable large pages if (using 2M region as example) > > (a) Mixed memory attributes. If a PFN falls into a 2M region, and parts > of that region are shared vs. private (mixed memory attributes -> > KVM_LPAGE_MIXED_FLAG) > > -> With gmem-shared we could have mixed memory attributes, not a PFN > fracturing. (PFNs don't depend on memory attributes) > > (b) page track: intercepting (mostly write) access to GFNs It's also used to handle misaligned memslots (or sizes), e.g. if a 1GiB memory region spanse 1GiB+4KiB => 2GiB+4KiB, KVM will disallow 1GiB hugepages, and 2MiB hugepages for the head and tails. Or if the host virtual address isn't aligned with the guest physical address (see above for guest_memfd's role when there is no hva). > So, I wonder if we still have to take care of lpage_info, at least for > handling (b) correctly [I assume so]. Ya, we do. > Regarding (a) I am not sure: once memory attributes are handled by gmem in > the gmem-shared case. IIRC, with AMD SEV we might still have to honor it? But > gmem itself could handle that. > > What we could definitely do here for now is: > > if (is_gmem) > /* gmem only supports 4k pages for now. */ > return PG_LEVEL_4K; > > And not worry about lpage_infor for the time being, until we actually do > support larger pages. I don't want to completely punt on this, because if it gets messy, then I want to know now and have a solution in hand, not find out N months from now. That said, I don't expect it to be difficult. What we could punt on is performance of the lookups, which is the real reason KVM maintains the rather expensive disallow_lpage array. And that said, memslots can only bind to one guest_memfd instance, so I don't immediately see any reason why the guest_memfd ioctl() couldn't process the slots that are bound to it. I.e. why not update KVM_LPAGE_MIXED_FLAG from the guest_memfd ioctl() instead of from KVM_SET_MEMORY_ATTRIBUTES?