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 27D7BC83F25 for ; Mon, 21 Jul 2025 16:44:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A81986B0089; Mon, 21 Jul 2025 12:44:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A595F6B008A; Mon, 21 Jul 2025 12:44:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96EFB6B008C; Mon, 21 Jul 2025 12:44:24 -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 807896B0089 for ; Mon, 21 Jul 2025 12:44:24 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1F5A3160122 for ; Mon, 21 Jul 2025 16:44:24 +0000 (UTC) X-FDA: 83688844848.22.05516A6 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) by imf16.hostedemail.com (Postfix) with ESMTP id 41FA7180010 for ; Mon, 21 Jul 2025 16:44:22 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=K+mc2c+G; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of 3ZG5-aAYKCIU1njwslpxxpun.lxvurw36-vvt4jlt.x0p@flex--seanjc.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3ZG5-aAYKCIU1njwslpxxpun.lxvurw36-vvt4jlt.x0p@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753116262; a=rsa-sha256; cv=none; b=AYtlLgKbkRwL/aKEuS22auXsuEuZaLdi01qYkRRDBEaq/TKjB3MwsfaHMxBTPX+sJm0kpP /L65+K96X9Dr7J8eq6eTHuUUJunFoRpStBa48OeFkzsHbd+uIMGmjTs3EqbfECB3TAaCqt YX8AlmqrQAsbiW+C6XIUXNu4s0L7+wE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=K+mc2c+G; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of 3ZG5-aAYKCIU1njwslpxxpun.lxvurw36-vvt4jlt.x0p@flex--seanjc.bounces.google.com designates 209.85.216.74 as permitted sender) smtp.mailfrom=3ZG5-aAYKCIU1njwslpxxpun.lxvurw36-vvt4jlt.x0p@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1753116262; 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=E2pDZoC0BnHT/ZCUH8bDZlPyb0AJitAQpL/OQ0QMPOw=; b=ZkoJ3ILIG5gqHnQsDAVvp40uHliHtBbsnB9wxGoNxr4yqkHWov1NmAylXoORypYPVhHyRK TMGkW1AcSrNFg/cDLzB2dNYWE/y2B2ZiIwzxX0iA6+Xn9OWtoJqr0Cahg8prr2RxWrbdPC PfIP6EZbaA550g78ABi5VBG3jtsvo+4= Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-311ae2b6647so4225701a91.0 for ; Mon, 21 Jul 2025 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1753116261; x=1753721061; 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=E2pDZoC0BnHT/ZCUH8bDZlPyb0AJitAQpL/OQ0QMPOw=; b=K+mc2c+GhFMqoFNjhhEK+x4JhRff56zjPCn1PWYcLtY7YxGjdSZC+tbj2ooU1TVcoL FC7uoJ580HmABcyfJDSNtSIRafTtzvbJYK8hm45rmd8qHIIn5uGMlfrawhdJg+Ybo0Eq d1I+L3MjnX5wzSw2ZNzh2NIgIniF1k+1Hnjj5348EUztxu/ZJOly09OlX2vsTG41FxmG e+Qpk1n4M+E7edzRrVycopyAOesftl1CYGB4hdHGIdMA0jg9TLIydPkjG6n12eVMJP1G 9ungkQxXZaaAVljJ87Y7PpcWIgr7vhTFU18P01G4M45MDEMKh2JIyyC+SpBwtpci0087 mZ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753116261; x=1753721061; 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=E2pDZoC0BnHT/ZCUH8bDZlPyb0AJitAQpL/OQ0QMPOw=; b=lnbkBgO3yuKpvV3oWatU9DhnHW+YEncqBLynnHXHOhJMuc+Y2ZMUZMUSz9CHe/+wjw YQ7KpKw5ZvO51xbnZ9TcfWh49FCbFfsV6XHqo4CtFghZdCd+DMf4jgYZd7GdHTeXyRUb QgHm/yU30a68xKBPXJvFpmrhSxcfYjjjkwAOiUE41t0kowfCqHmxC+tDixSyRamHTQXs uyqVB1FdyJ6fWsIKbVxFdLOnytvku1uxqE4bV9KVkmLO4O6SenSVqjs59KOx6lCbvYlu rbHabZqEHsksNUkNH4j6dTgwGD7vPEGFGOPerwTudMIpMaVTUde+1UPAk+LXjkOIXQEc 0F7Q== X-Forwarded-Encrypted: i=1; AJvYcCWpZoL2rJYZTKD/p1tGLSS7NacSYSHgZDSQxby+6S1p+3BkoRdIxqgvBrilSOTmj0g0730tcd7sqg==@kvack.org X-Gm-Message-State: AOJu0YzGrBSHEvWyfljnhbT9KxBpXsEK1SyIoshsYe30i4ExZL4jAKGD nKDK0/vITDKEFVPSrH854PgdE/yx08FGkQHTvJ6l3G9wtXFCONQ3avRWRZ0ycRb3hEXvT6092Ui ZlbzDXA== X-Google-Smtp-Source: AGHT+IGV3txk15pDg0M1Ed03xNgjsDtAy6U2A0NIrZT4Nq2Cw7NmK/8BmQSWlnlb3cR2CyxAqDvz4zMJ9eI= X-Received: from pjbph15.prod.google.com ([2002:a17:90b:3bcf:b0:313:285a:5547]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1d06:b0:311:afd1:745b with SMTP id 98e67ed59e1d1-31cc254053emr20093665a91.11.1753116260899; Mon, 21 Jul 2025 09:44:20 -0700 (PDT) Date: Mon, 21 Jul 2025 09:44:19 -0700 In-Reply-To: <20250717162731.446579-3-tabba@google.com> Mime-Version: 1.0 References: <20250717162731.446579-1-tabba@google.com> <20250717162731.446579-3-tabba@google.com> Message-ID: Subject: Re: [PATCH v15 02/21] KVM: Rename CONFIG_KVM_GENERIC_PRIVATE_MEM to CONFIG_KVM_GENERIC_GMEM_POPULATE From: Sean Christopherson To: Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, kvmarm@lists.linux.dev, 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, ackerleytng@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, ira.weiny@intel.com Content-Type: text/plain; charset="us-ascii" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 41FA7180010 X-Stat-Signature: 3pcakiwsqzxw1k167o9phc4naoqcn4ry X-Rspam-User: X-HE-Tag: 1753116262-784511 X-HE-Meta: U2FsdGVkX19EMpM3xvsJzfmPqSfZoAVsDPIkXhN/gTgxzA6h1R50N1P9x0a0bsF54+COef3+5kVZFCrdGyFZzlKgVW8kiSTdPtldTcvBX+BqB0CRppJkI2GR9ODivCf1J1u5WF700fso9+eM9w9kMdZiZXwSLojPM35egeakeIPvy/VnSwTK+2SKSvBA58kLbivFvdc8AhdxFYCy3rNj/V3ttUFu48/N6EcMZ6sJUJqK34IsVf7zFzynntZCFFgc1IFdYuTZx4WFXm6EGkdKPrva9BGDKe0RgUs9Xglq7hmFDTC2eH1gPlWYYDxQKZrCsfAipCi/T2xbhNtWLQWJyWMHUzbVGefeSoZoYw8bkMluCc5EVYVLJ1o26lWVoqr+2x4/DYTSloamzY7OuxQjbOctdzZAzICSuYYevo0Fx2j9qFjMyK3dOhmypjtZS8i3WorSiQ89B4rPsKPNlhOAhDuAMaio+FOkX9ZqcSabw0tgcN/DrqTQCstpaQciX25OgwWPvRs1dzMzeJdKOQx5SRW3YMR+EOXzo0zwxKhETbH0SAC5Af5asFF81OQsHL7ERp810PHDhU3EeUj8N35JSIiB9Wiou4iDTbDc3CxUgl4KkJQEue97M8O6hvgpwsAjTasn92MuGhqOwEjbeQUN8qk2XEDVjC1zRdF69wCEGLSyhql87qwBhG7CobUGuoGqV0eARISpPutpZh09RLY/TbL0IGBvtyLvBviAYy2tjYvjltig0vfkDj+kJsq6lJ5oNGtW6YULo406Y9rydXEWbGVGDzItjmx4eEr3g7cf3ekkXjOGzIziYbmA8euuynbVIm98/80l2hQzDdSRbQgsco9bZzMZCQ9UxQGYCSe5jb1SkiKFyt8xGv0OquANA5MXRQTFHINIQn+mnONl0JHe+XRCu0hDMBCEVAmIM2Ni2kgMhhS7fIvtznr6sVZ+N8wN7PlpxKtP90wAwHeBUFd GtQzDvpb JlWy398G8WOHb1BxorN7EP16tHC63SzgrqQU7cDOpmFcYegvrONiNLf1BDiWZp91otx5vLQWkf/v+jzjKLkeWHK2Dn4Tr0znpeVNFS+ARHuocLIBVm694OGp/YA+Ov5C/n4nPMe9wMM1pvPgNv8E+8ItSAcy8UNuMiG590o7kxnXBIJYQ479iKintrIasZhxhRB1WRmeYEw5oDNJHffmDzM6gKjqdT66ANzDfRwMOVdZASBeb4YjZT+/bxohIVB4L8jRS6+mcLQKNavQhw9VQpYYDZRPWdxZ9+bcvf8o3r5dVLz7jp7I5FoEme48XkPjb9JsISrnNzsYW/l91fibl8/CysB5Jb6agtHDVhLylKgJTUdxL0lCdzh0AmY+zVZftvlRwhzHBZ0KsPV3FrACiPYNZ7eVIC/zbtMOk+fpxewitLP3BKXLh44A5fag/jUagVZALLJXVzYuCBs2MWUUkuipxwb9ldoF4Di99KzcUn99zmSKE60YcY0ubHUj66yngExBeNFYPMTz8S0B+nY+pxq9uHdDLQ+ymhkqzUPOyjCMEOW72HuzRgUr8y6+Nnvd4kcVd23oRzRp3RBvX96C5wKMaCtmGfW2q9BkRSC3/jtrX6TnKMDj4bHtMb0qfU+YWevUTvEhVCpU/NQftCN5kh1nxMVv7P/iy1QSAaaNln3jXVpMn6MWW/Elf0pGrQx6FYOPpVnmicVQUKa0grFEaEGRujbTk33G1LWQRiQTUrHogCrwyiqU33GPCV73oJQ60icN8BdLJ2yzegkMa2nlZPj5NeyoWkDCGEUrHV+MpNqFRxg8= 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, Jul 17, 2025, Fuad Tabba wrote: > The original name was vague regarding its functionality. It was intentionally vague/broad so that KVM didn't end up with an explosion of Kconfigs. > This Kconfig option specifically enables and gates the kvm_gmem_populate() > function, which is responsible for populating a GPA range with guest data. And obviously selects KVM_GENERIC_MEMORY_ATTRIBUTES... > The new name, KVM_GENERIC_GMEM_POPULATE, describes the purpose of the > option: to enable generic guest_memfd population mechanisms. As above, the purpose of KVM_GENERIC_PRIVATE_MEM isn't just to enable kvm_gmem_populate(). In fact, the Kconfig predates kvm_gmem_populate(). The main reason KVM_GENERIC_PRIVATE_MEM was added was to avoid having to select the same set of Kconfigs in every flavor of CoCo-ish VM, i.e. was to avoid what this patch does. There was a bit of mis-speculation in that x86 ended up being the only arch that wants KVM_GENERIC_MEMORY_ATTRIBUTES, so we should simply remedy that. Providing KVM_PRIVATE_MEM in x86 would also clean up this mess: select KVM_GMEM if KVM_SW_PROTECTED_VM select KVM_GENERIC_MEMORY_ATTRIBUTES if KVM_SW_PROTECTED_VM select KVM_GMEM_SUPPORTS_MMAP if X86_64 Where KVM_GMEM_SUPPORTS_MMAP and thus KVM_GUEST_MEMFD is selected by X86_64. I.e. X86_64 is subtly *unconditionally* enabling guest_memfd. I have no objection to always supporting guest_memfd for 64-bit, but it should be obvious, not buried in a Kconfig config. More importantly, the above means it's impossible to have KVM_GMEM without KVM_GMEM_SUPPORTS_MMAP, because arm64 always selects KVM_GMEM_SUPPORTS_MMAP, and x86 can only select KVM_GMEM when KVM_GMEM_SUPPORTS_MMAP is forced/selected. Following that trail of breadcrumbs, x86 ends up with another tautology that isn't captured. kvm_arch_supports_gmem() is true for literally every type of VM. It isn't true for every #defined VM type, since it's not allowed for KVM_X86_SEV_VM or KVM_X86_SEV_ES_VM. But those are recent additions that are entirely optional. I.e. userspace can create SEV and/or SEV-ES VMs using KVM_X86_DEFAULT_VM. And if we fix that oddity, and follow more breadcrumbs, we arrive at kvm_arch_supports_gmem_mmap(), where it unnecessarily open codes a check on KVM_X86_DEFAULT_VM when in fact the real restriction is that guest_memfd mmap() is currently incompatible with kvm_arch_has_private_mem(). I already have a NAK typed up for patch 3 for completely unrelated reasons (adding arch.supports_gmem creates unnecessary potential for bugs, e.g. allows checking kvm_arch_supports_gmem() before the flag is set). That's all the more reason to kill off as many of these #defines and checks as possible. Oh, and that also ties into Xiaoyao's question about what to do with mapping guest_memfd into a memslot without a guest_memfd file descriptor. Once we add private vs. shared tracking in guest_memfd, kvm_arch_supports_gmem_mmap() becomes true if CONFIG_KVM_GUEST_MEMFD=y. Heh, so going through all of that, KVM_PRIVATE_MEM just ends up being this: config KVM_PRIVATE_MEM depends on X86_64 select KVM_GENERIC_MEMORY_ATTRIBUTES bool which means my initial feedback that prompted this becomes null and void :-) That said, I think we should take this opportunity to select KVM_GENERIC_MEMORY_ATTRIBUTES directly instead of having it selected from "config KVM". There's a similar oddity with TDX. > improves clarity for developers and ensures the name accurately reflects > the functionality it controls, especially as guest_memfd support expands > beyond purely "private" memory scenarios. > > Note that the vm type KVM_X86_SW_PROTECTED_VM does not need the populate > function. Therefore, ensure that the correct configuration is selected > when KVM_SW_PROTECTED_VM is enabled. > > Reviewed-by: Ira Weiny > Reviewed-by: Gavin Shan > Reviewed-by: Shivank Garg > Reviewed-by: Vlastimil Babka > Co-developed-by: David Hildenbrand > Signed-off-by: David Hildenbrand > Signed-off-by: Fuad Tabba > --- > arch/x86/kvm/Kconfig | 7 ++++--- > include/linux/kvm_host.h | 2 +- > virt/kvm/Kconfig | 2 +- > virt/kvm/guest_memfd.c | 2 +- > 4 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > index 2eeffcec5382..12e723bb76cc 100644 > --- a/arch/x86/kvm/Kconfig > +++ b/arch/x86/kvm/Kconfig > @@ -46,7 +46,8 @@ config KVM_X86 > select HAVE_KVM_PM_NOTIFIER if PM > select KVM_GENERIC_HARDWARE_ENABLING > select KVM_GENERIC_PRE_FAULT_MEMORY > - select KVM_GENERIC_PRIVATE_MEM if KVM_SW_PROTECTED_VM > + select KVM_GMEM if KVM_SW_PROTECTED_VM > + select KVM_GENERIC_MEMORY_ATTRIBUTES if KVM_SW_PROTECTED_VM > select KVM_WERROR if WERROR > > config KVM > @@ -95,7 +96,7 @@ config KVM_SW_PROTECTED_VM > config KVM_INTEL > tristate "KVM for Intel (and compatible) processors support" > depends on KVM && IA32_FEAT_CTL > - select KVM_GENERIC_PRIVATE_MEM if INTEL_TDX_HOST > + select KVM_GENERIC_GMEM_POPULATE if INTEL_TDX_HOST > select KVM_GENERIC_MEMORY_ATTRIBUTES if INTEL_TDX_HOST > help > Provides support for KVM on processors equipped with Intel's VT > @@ -157,7 +158,7 @@ config KVM_AMD_SEV > depends on KVM_AMD && X86_64 > depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m) > select ARCH_HAS_CC_PLATFORM > - select KVM_GENERIC_PRIVATE_MEM > + select KVM_GENERIC_GMEM_POPULATE > select HAVE_KVM_ARCH_GMEM_PREPARE > select HAVE_KVM_ARCH_GMEM_INVALIDATE > help > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 755b09dcafce..359baaae5e9f 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -2556,7 +2556,7 @@ static inline int kvm_gmem_get_pfn(struct kvm *kvm, > int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int max_order); > #endif > > -#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > +#ifdef CONFIG_KVM_GENERIC_GMEM_POPULATE > /** > * kvm_gmem_populate() - Populate/prepare a GPA range with guest data > * > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > index 49df4e32bff7..559c93ad90be 100644 > --- a/virt/kvm/Kconfig > +++ b/virt/kvm/Kconfig > @@ -116,7 +116,7 @@ config KVM_GMEM > select XARRAY_MULTI > bool > > -config KVM_GENERIC_PRIVATE_MEM > +config KVM_GENERIC_GMEM_POPULATE > select KVM_GENERIC_MEMORY_ATTRIBUTES > select KVM_GMEM This is where things really start to break down. Selecting KVM_GUEST_MEMFD and KVM_GENERIC_MEMORY_ATTRIBUTES when KVM_GENERIC_PRIVATE_MEM=y is decent logic. *Selecting* KVM_GUEST_MEMFD from a sub-feature of guest_memfd is weird. I don't love HAVE_KVM_ARCH_GMEM_INVALIDATE and HAVE_KVM_ARCH_GMEM_PREPARE, as I think they're too fine-grained. But that's largely an orthogonal problem, and it's not clear that bundling them together would be an improvement. So, I think we should just follow those and add HAVE_KVM_ARCH_GMEM_POPULATE, selected by SEV and TDX. The below diff applies on top. I'm guessing there may be some intermediate ugliness (I haven't mapped out exactly where/how to squash this throughout the series, and there is feedback relevant to future patches), but IMO this is a much cleaner resting state (see the diff stats). --- arch/arm64/include/asm/kvm_host.h | 5 ----- arch/arm64/kvm/Kconfig | 3 +-- arch/x86/include/asm/kvm_host.h | 15 +------------- arch/x86/kvm/Kconfig | 10 +++++---- arch/x86/kvm/x86.c | 13 ++++++++++-- include/linux/kvm_host.h | 34 +++++-------------------------- virt/kvm/Kconfig | 11 +++------- virt/kvm/guest_memfd.c | 10 +++++---- virt/kvm/kvm_main.c | 8 +++----- 9 files changed, 36 insertions(+), 73 deletions(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 63f7827cfa1b..3408174ec945 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -1674,9 +1674,4 @@ void compute_fgu(struct kvm *kvm, enum fgt_group_id fgt); void get_reg_fixed_bits(struct kvm *kvm, enum vcpu_sysreg reg, u64 *res0, u64 *res1); void check_feature_map(void); -#ifdef CONFIG_KVM_GMEM -#define kvm_arch_supports_gmem(kvm) true -#define kvm_arch_supports_gmem_mmap(kvm) IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP) -#endif - #endif /* __ARM64_KVM_HOST_H__ */ diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 323b46b7c82f..bff62e75d681 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -37,8 +37,7 @@ menuconfig KVM select HAVE_KVM_VCPU_RUN_PID_CHANGE select SCHED_INFO select GUEST_PERF_EVENTS if PERF_EVENTS - select KVM_GMEM - select KVM_GMEM_SUPPORTS_MMAP + select KVM_GUEST_MEMFD help Support hosting virtualized guest machines. diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index e1426adfa93e..d93560769465 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -2276,21 +2276,8 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level, int tdp_max_root_level, int tdp_huge_page_level); -#ifdef CONFIG_KVM_GMEM +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.has_private_mem) -#define kvm_arch_supports_gmem(kvm) ((kvm)->arch.supports_gmem) - -/* - * CoCo VMs with hardware support that use guest_memfd only for backing private - * memory, e.g., TDX, cannot use guest_memfd with userspace mapping enabled. - */ -#define kvm_arch_supports_gmem_mmap(kvm) \ - (IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP) && \ - (kvm)->arch.vm_type == KVM_X86_DEFAULT_VM) -#else -#define kvm_arch_has_private_mem(kvm) false -#define kvm_arch_supports_gmem(kvm) false -#define kvm_arch_supports_gmem_mmap(kvm) false #endif #define kvm_arch_has_readonly_mem(kvm) (!(kvm)->arch.has_protected_state) diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index 2eeffcec5382..afcf8628f615 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -46,8 +46,8 @@ config KVM_X86 select HAVE_KVM_PM_NOTIFIER if PM select KVM_GENERIC_HARDWARE_ENABLING select KVM_GENERIC_PRE_FAULT_MEMORY - select KVM_GENERIC_PRIVATE_MEM if KVM_SW_PROTECTED_VM select KVM_WERROR if WERROR + select KVM_GUEST_MEMFD if X86_64 config KVM tristate "Kernel-based Virtual Machine (KVM) support" @@ -84,6 +84,7 @@ config KVM_SW_PROTECTED_VM bool "Enable support for KVM software-protected VMs" depends on EXPERT depends on KVM && X86_64 + select KVM_GENERIC_MEMORY_ATTRIBUTES help Enable support for KVM software-protected VMs. Currently, software- protected VMs are purely a development and testing vehicle for @@ -95,8 +96,6 @@ config KVM_SW_PROTECTED_VM config KVM_INTEL tristate "KVM for Intel (and compatible) processors support" depends on KVM && IA32_FEAT_CTL - select KVM_GENERIC_PRIVATE_MEM if INTEL_TDX_HOST - select KVM_GENERIC_MEMORY_ATTRIBUTES if INTEL_TDX_HOST help Provides support for KVM on processors equipped with Intel's VT extensions, a.k.a. Virtual Machine Extensions (VMX). @@ -135,6 +134,8 @@ config KVM_INTEL_TDX bool "Intel Trust Domain Extensions (TDX) support" default y depends on INTEL_TDX_HOST + select KVM_GENERIC_MEMORY_ATTRIBUTES + select HAVE_KVM_ARCH_GMEM_POPULATE help Provides support for launching Intel Trust Domain Extensions (TDX) confidential VMs on Intel processors. @@ -157,9 +158,10 @@ config KVM_AMD_SEV depends on KVM_AMD && X86_64 depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m) select ARCH_HAS_CC_PLATFORM - select KVM_GENERIC_PRIVATE_MEM + select KVM_GENERIC_MEMORY_ATTRIBUTES select HAVE_KVM_ARCH_GMEM_PREPARE select HAVE_KVM_ARCH_GMEM_INVALIDATE + select HAVE_KVM_ARCH_GMEM_POPULATE help Provides support for launching encrypted VMs which use Secure Encrypted Virtualization (SEV), Secure Encrypted Virtualization with diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index ca99187a566e..b6961b4b7aee 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12781,8 +12781,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) kvm->arch.vm_type = type; kvm->arch.has_private_mem = (type == KVM_X86_SW_PROTECTED_VM); - kvm->arch.supports_gmem = - type == KVM_X86_DEFAULT_VM || type == KVM_X86_SW_PROTECTED_VM; /* Decided by the vendor code for other VM types. */ kvm->arch.pre_fault_allowed = type == KVM_X86_DEFAULT_VM || type == KVM_X86_SW_PROTECTED_VM; @@ -13708,6 +13706,16 @@ bool kvm_arch_no_poll(struct kvm_vcpu *vcpu) } EXPORT_SYMBOL_GPL(kvm_arch_no_poll); +#ifdef CONFIG_KVM_GUEST_MEMFD +/* + * KVM doesn't yet support mmap() on guest_memfd for VMs with private memory + * (the private vs. shared tracking needs to be moved into guest_memfd). + */ +bool kvm_arch_supports_gmem_mmap(struct kvm *kvm) +{ + return !kvm_arch_has_private_mem(kvm); +} + #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_PREPARE int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int max_order) { @@ -13721,6 +13729,7 @@ void kvm_arch_gmem_invalidate(kvm_pfn_t start, kvm_pfn_t end) kvm_x86_call(gmem_invalidate)(start, end); } #endif +#endif int kvm_spec_ctrl_test_value(u64 value) { diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 2c1dcd3967d9..a9f31b2b63b1 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -719,39 +719,15 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu) } #endif -/* - * Arch code must define kvm_arch_has_private_mem if support for guest_memfd is - * enabled. - */ -#if !defined(kvm_arch_has_private_mem) && !IS_ENABLED(CONFIG_KVM_GMEM) +#ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES static inline bool kvm_arch_has_private_mem(struct kvm *kvm) { return false; } #endif -/* - * Arch code must define kvm_arch_supports_gmem if support for guest_memfd is - * enabled. - */ -#if !defined(kvm_arch_supports_gmem) && !IS_ENABLED(CONFIG_KVM_GMEM) -static inline bool kvm_arch_supports_gmem(struct kvm *kvm) -{ - return false; -} -#endif - -/* - * Returns true if this VM supports mmap() in guest_memfd. - * - * Arch code must define kvm_arch_supports_gmem_mmap if support for guest_memfd - * is enabled. - */ -#if !defined(kvm_arch_supports_gmem_mmap) -static inline bool kvm_arch_supports_gmem_mmap(struct kvm *kvm) -{ - return false; -} +#ifdef CONFIG_KVM_GUEST_MEMFD +bool kvm_arch_supports_gmem_mmap(struct kvm *kvm); #endif #ifndef kvm_arch_has_readonly_mem @@ -2539,7 +2515,7 @@ static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu, static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot) { - if (!IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP)) + if (!IS_ENABLED(CONFIG_KVM_GUEST_MEMFD)) return false; return slot->flags & KVM_MEMSLOT_GMEM_ONLY; @@ -2596,7 +2572,7 @@ static inline int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot, int kvm_arch_gmem_prepare(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int max_order); #endif -#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE /** * kvm_gmem_populate() - Populate/prepare a GPA range with guest data * diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig index 96cf4ab0d534..9d472f46ebf1 100644 --- a/virt/kvm/Kconfig +++ b/virt/kvm/Kconfig @@ -112,15 +112,10 @@ config KVM_GENERIC_MEMORY_ATTRIBUTES depends on KVM_GENERIC_MMU_NOTIFIER bool -config KVM_GMEM +config KVM_GUEST_MEMFD select XARRAY_MULTI bool -config KVM_GENERIC_PRIVATE_MEM - select KVM_GENERIC_MEMORY_ATTRIBUTES - select KVM_GMEM - bool - config HAVE_KVM_ARCH_GMEM_PREPARE bool depends on KVM_GMEM @@ -129,6 +124,6 @@ config HAVE_KVM_ARCH_GMEM_INVALIDATE bool depends on KVM_GMEM -config KVM_GMEM_SUPPORTS_MMAP - select KVM_GMEM +config HAVE_KVM_ARCH_GMEM_POPULATE bool + depends on KVM_GMEM \ No newline at end of file diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index d01bd7a2c2bd..57db0041047a 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -316,9 +316,6 @@ static bool kvm_gmem_supports_mmap(struct inode *inode) { const u64 flags = (u64)inode->i_private; - if (!IS_ENABLED(CONFIG_KVM_GMEM_SUPPORTS_MMAP)) - return false; - return flags & GUEST_MEMFD_FLAG_MMAP; } @@ -527,6 +524,11 @@ static int __kvm_gmem_create(struct kvm *kvm, loff_t size, u64 flags) return err; } +bool __weak kvm_arch_supports_gmem_mmap(struct kvm *kvm) +{ + return true; +} + int kvm_gmem_create(struct kvm *kvm, struct kvm_create_guest_memfd *args) { loff_t size = args->size; @@ -730,7 +732,7 @@ int kvm_gmem_mapping_order(const struct kvm_memory_slot *slot, gfn_t gfn) } EXPORT_SYMBOL_GPL(kvm_gmem_mapping_order); -#ifdef CONFIG_KVM_GENERIC_GMEM_POPULATE +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE long kvm_gmem_populate(struct kvm *kvm, gfn_t start_gfn, void __user *src, long npages, kvm_gmem_populate_cb post_populate, void *opaque) { diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f1ac872e01e9..1b609e35303f 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1588,7 +1588,7 @@ static int check_memory_region_flags(struct kvm *kvm, { u32 valid_flags = KVM_MEM_LOG_DIRTY_PAGES; - if (kvm_arch_supports_gmem(kvm)) + if (IS_ENABLED(CONFIG_KVM_GUEST_MEMFD)) valid_flags |= KVM_MEM_GUEST_MEMFD; /* Dirty logging private memory is not currently supported. */ @@ -4915,10 +4915,8 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) #endif #ifdef CONFIG_KVM_GMEM case KVM_CAP_GUEST_MEMFD: - return !kvm || kvm_arch_supports_gmem(kvm); -#endif -#ifdef CONFIG_KVM_GMEM_SUPPORTS_MMAP - case KVM_CAP_GMEM_MMAP: + return 1; + case KVM_CAP_GUEST_MEMFD_MMAP: return !kvm || kvm_arch_supports_gmem_mmap(kvm); #endif default: base-commit: 9eba3a9ac9cd5922da7f6e966c01190f909ed640 --