Changes in Kconfig

459a3511 - KVM: Allow building irqbypass.ko as as module when kvm.ko is a module

Sat, 15 Mar 2025 02:46:23 +0000

KVM: Allow building irqbypass.ko as as module when kvm.ko is a moduleConvert HAVE_KVM_IRQ_BYPASS into a tristate so that selectingIRQ_BYPASS_MANAGER follows KVM={m,y}, i.e. doesn't force irqbypass.ko tobe built-in.Note, PPC allows building KVM as a module, but selects HAVE_KVM_IRQ_BYPASSfrom a boolean Kconfig, i.e. KVM PPC unnecessarily forces irqbpass.ko tobe built-in. But that flaw is a longstanding PPC specific issue.Fixes: 61df71ee992d ("kvm: move "select IRQ_BYPASS_MANAGER" to common code")Cc: stable@vger.kernel.orgSigned-off-by: Sean Christopherson Message-ID: <20250315024623.2363994-1-seanjc@google.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

aa34b811 - KVM: Allow lockless walk of SPTEs when handing aging mmu_notifier event

Tue, 04 Feb 2025 00:40:29 +0000

KVM: Allow lockless walk of SPTEs when handing aging mmu_notifier eventIt is possible to correctly do aging without taking the KVM MMU lock,or while taking it for read; add a Kconfig to let architectures do so.Architectures that select KVM_MMU_LOCKLESS_AGING are responsible forcorrectness.Suggested-by: Yu Zhao Signed-off-by: James Houghton Reviewed-by: David Matlack Link: https://lore.kernel.org/r/20250204004038.1680123-3-jthoughton@google.com[sean: massage shortlog+changelog, fix Kconfig goof and shorten name]Signed-off-by: Sean Christopherson List of files: /linux-6.15/virt/kvm/Kconfig

2ebbe030 - KVM: Allow arch code to elide TLB flushes when aging a young page

Fri, 11 Oct 2024 02:10:49 +0000

KVM: Allow arch code to elide TLB flushes when aging a young pageAdd a Kconfig to allow architectures to opt-out of a TLB flush when ayoung page is aged, as invalidating TLB entries is not functionallyrequired on most KVM-supported architectures. Stale TLB entries canresult in false negatives and theoretically lead to suboptimal reclaim,but in practice all observations have been that the performance gained byskipping TLB flushes outweighs any performance lost by reclaiming hotpages.E.g. the primary MMUs for x86 RISC-V, s390, and PPC Book3S elide the TLBflush for ptep_clear_flush_young(), and arm64's MMU skips the trailing DSBthat's required for ordering (presumably because there are optimizationsrelated to eliding other TLB flushes when doing make-before-break).Link: https://lore.kernel.org/r/20241011021051.1557902-18-seanjc@google.comSigned-off-by: Sean Christopherson List of files: /linux-6.15/virt/kvm/Kconfig

564429a6 - KVM: rename CONFIG_HAVE_KVM_GMEM_* to CONFIG_HAVE_KVM_ARCH_GMEM_*

Thu, 11 Jul 2024 22:27:47 +0000

KVM: rename CONFIG_HAVE_KVM_GMEM_* to CONFIG_HAVE_KVM_ARCH_GMEM_*Add "ARCH" to the symbols; shortly, the "prepare" phase will include boththe arch-independent step to clear out contents left in the page by thehost, and the arch-dependent step enabled by CONFIG_HAVE_KVM_GMEM_PREPARE.For consistency do the same for CONFIG_HAVE_KVM_GMEM_INVALIDATE as well.Reviewed-by: Michael Roth Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

bc1a5cd0 - KVM: Add KVM_PRE_FAULT_MEMORY vcpu ioctl to pre-populate guest memory

Wed, 10 Apr 2024 22:07:28 +0000

KVM: Add KVM_PRE_FAULT_MEMORY vcpu ioctl to pre-populate guest memoryAdd a new ioctl KVM_PRE_FAULT_MEMORY in the KVM common code. It iterates on thememory range and calls the arch-specific function. The implementation isoptional and enabled by a Kconfig symbol.Suggested-by: Sean Christopherson Signed-off-by: Isaku Yamahata Reviewed-by: Rick Edgecombe Message-ID: <819322b8f25971f2b9933bfa4506e618508ad782.1712785629.git.isaku.yamahata@intel.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

a90764f0 - KVM: guest_memfd: Add hook for invalidating memory

Sat, 30 Dec 2023 17:23:21 +0000

KVM: guest_memfd: Add hook for invalidating memoryIn some cases, like with SEV-SNP, guest memory needs to be updated in aplatform-specific manner before it can be safely freed back to the host.Wire up arch-defined hooks to the .free_folio kvm_gmem_aops callback toallow for special handling of this sort when freeing memory in responseto FALLOC_FL_PUNCH_HOLE operations and when releasing the inode, and goahead and define an arch-specific hook for x86 since it will be neededfor handling memory used for SEV-SNP guests.Signed-off-by: Michael Roth Message-Id: <20231230172351.574091-6-michael.roth@amd.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

3bb2531e - KVM: guest_memfd: Add hook for initializing memory

Tue, 07 May 2024 16:54:03 +0000

KVM: guest_memfd: Add hook for initializing memoryguest_memfd pages are generally expected to be in some arch-definedinitial state prior to using them for guest memory. For SEV-SNP thisinitial state is 'private', or 'guest-owned', and requires additionaloperations to move these pages into a 'private' state by updating thecorresponding entries the RMP table.Allow for an arch-defined hook to handle updates of this sort, and goahead and implement one for x86 so KVM implementations like AMD SVM canregister a kvm_x86_ops callback to handle these updates for SEV-SNPguests.The preparation callback is always called when allocating/grabbingfolios via gmem, and it is up to the architecture to keep track ofwhether or not the pages are already in the expected state (e.g. the RMPtable in the case of SEV-SNP).In some cases, it is necessary to defer the preparation of the pages tohandle things like in-place encryption of initial guest memory payloadsbefore marking these pages as 'private'/'guest-owned'. Add an argument(always true for now) to kvm_gmem_get_folio() that allows for thepreparation callback to be bypassed. To detect possible issues inthe way userspace initializes memory, it is only possible to add anunprepared page if it is not already included in the filemap.Link: https://lore.kernel.org/lkml/ZLqVdvsF11Ddo7Dq@google.com/Co-developed-by: Michael Roth Signed-off-by: Michael Roth Message-Id: <20231230172351.574091-5-michael.roth@amd.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

f48212ee - treewide: remove CONFIG_HAVE_KVM

Thu, 04 Jan 2024 16:34:25 +0000

treewide: remove CONFIG_HAVE_KVMIt has no users anymore.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

61df71ee - kvm: move "select IRQ_BYPASS_MANAGER" to common code

Thu, 11 Jan 2024 08:02:05 +0000

kvm: move "select IRQ_BYPASS_MANAGER" to common codeCONFIG_IRQ_BYPASS_MANAGER is a dependency of the common code included byCONFIG_HAVE_KVM_IRQ_BYPASS. There is no advantage in adding the corresponding"select" directive to each architecture.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

8886640d - kvm: replace __KVM_HAVE_READONLY_MEM with Kconfig symbol

Thu, 11 Jan 2024 08:00:34 +0000

kvm: replace __KVM_HAVE_READONLY_MEM with Kconfig symbolKVM uses __KVM_HAVE_* symbols in the architecture-dependent uapi/asm/kvm.h to maskunused definitions in include/uapi/linux/kvm.h. __KVM_HAVE_READONLY_MEM howeverwas nothing but a misguided attempt to define KVM_CAP_READONLY_MEM only onarchitectures where KVM_CHECK_EXTENSION(KVM_CAP_READONLY_MEM) could possiblyreturn nonzero. This however does not make sense, and it prevented userspacefrom supporting this architecture-independent feature without recompilation.Therefore, these days __KVM_HAVE_READONLY_MEM does not mask anything andis only used in virt/kvm/kvm_main.c. Userspace does not need to test itand there should be no need for it to exist. Remove it and replace itwith a Kconfig symbol within Linux source code.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

3a373e02 - KVM: fix direction of dependency on MMU notifiers

Sat, 06 Jan 2024 07:24:00 +0000

KVM: fix direction of dependency on MMU notifiersKVM_GENERIC_MEMORY_ATTRIBUTES requires the generic MMU notifier code, becauseit uses kvm_mmu_invalidate_begin/end. However, it would not work with a bespokeimplementation of MMU notifiers that does not use KVM_GENERIC_MMU_NOTIFIER,because most likely it would not synchronize correctly on invalidation. Sothe right thing to do is to note the problematic configuration if thearchitecture does not select itself KVM_GENERIC_MMU_NOTIFIER; not toenable it blindly.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

caadf876 - KVM: introduce CONFIG_KVM_COMMON

Thu, 04 Jan 2024 16:15:07 +0000

KVM: introduce CONFIG_KVM_COMMONCONFIG_HAVE_KVM is currently used by some architectures to eitherenabled the KVM config proper, or to enable host-side code that isnot part of the KVM module. However, CONFIG_KVM's "select" statementin virt/kvm/Kconfig corresponds to a third meaning, namely toenable common Kconfigs required by all architectures that supportKVM.These three meanings can be replaced respectively by anarchitecture-specific Kconfig, by IS_ENABLED(CONFIG_KVM), or bya new Kconfig symbol that is in turn selected by thearchitecture-specific "config KVM".Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON.Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not byarchitecture code, and it brings in all dependencies of commonKVM code. In particular, INTERVAL_TREE was missing in loongarchand riscv, so that is another thing that is fixed.Fixes: 8132d887a702 ("KVM: remove CONFIG_HAVE_KVM_EVENTFD", 2023-12-08)Reported-by: Randy Dunlap Closes: https://lore.kernel.org/all/44907c6b-c5bd-4e4a-a921-e4d3825539d8@infradead.org/Reviewed-by: Andrew Jones Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

c5b31cc2 - KVM: remove CONFIG_HAVE_KVM_IRQFD

Wed, 18 Oct 2023 16:07:32 +0000

KVM: remove CONFIG_HAVE_KVM_IRQFDAll platforms with a kernel irqchip have support for irqfd. Unify thetwo configuration items so that userspace can expect to use irqfd toinject interrupts into the irqchip.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

8132d887 - KVM: remove CONFIG_HAVE_KVM_EVENTFD

Wed, 18 Oct 2023 16:11:56 +0000

KVM: remove CONFIG_HAVE_KVM_EVENTFDvirt/kvm/eventfd.c is compiled unconditionally, meaning that the ioeventfdsmember of struct kvm is accessed unconditionally. CONFIG_HAVE_KVM_EVENTFDtherefore must be defined for KVM common code to compile successfully,remove it.Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

89ea60c2 - KVM: x86: Add support for "protected VMs" that can utilize private memory

Fri, 27 Oct 2023 18:22:05 +0000

KVM: x86: Add support for "protected VMs" that can utilize private memoryAdd a new x86 VM type, KVM_X86_SW_PROTECTED_VM, to serve as a developmentand testing vehicle for Confidential (CoCo) VMs, and potentially to evenbecome a "real" product in the distant future, e.g. a la pKVM.The private memory support in KVM x86 is aimed at AMD's SEV-SNP andIntel's TDX, but those technologies are extremely complex (understatement),difficult to debug, don't support running as nested guests, and requirehardware that's isn't universally accessible. I.e. relying SEV-SNP or TDXfor maintaining guest private memory isn't a realistic option.At the very least, KVM_X86_SW_PROTECTED_VM will enable a variety ofselftests for guest_memfd and private memory support without requiringunique hardware.Signed-off-by: Sean Christopherson Reviewed-by: Paolo Bonzini Message-Id: <20231027182217.3615211-24-seanjc@google.com>Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

a7800aa8 - KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory

Mon, 13 Nov 2023 10:42:34 +0000

KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memoryIntroduce an ioctl(), KVM_CREATE_GUEST_MEMFD, to allow creating file-basedmemory that is tied to a specific KVM virtual machine and whose primarypurpose is to serve guest memory.A guest-first memory subsystem allows for optimizations and enhancementsthat are kludgy or outright infeasible to implement/support in a genericmemory subsystem. With guest_memfd, guest protections and mapping sizesare fully decoupled from host userspace mappings. E.g. KVM currentlydoesn't support mapping memory as writable in the guest without it alsobeing writable in host userspace, as KVM's ABI uses VMA protections todefine the allow guest protection. Userspace can fudge this byestablishing two mappings, a writable mapping for the guest and readableone for itself, but that’s suboptimal on multiple fronts.Similarly, KVM currently requires the guest mapping size to be a strictsubset of the host userspace mapping size, e.g. KVM doesn’t supportcreating a 1GiB guest mapping unless userspace also has a 1GiB guestmapping. Decoupling the mappings sizes would allow userspace to preciselymap only what is needed without impacting guest performance, e.g. toharden against unintentional accesses to guest memory.Decoupling guest and userspace mappings may also allow for a cleaneralternative to high-granularity mappings for HugeTLB, which has reached abit of an impasse and is unlikely to ever be merged.A guest-first memory subsystem also provides clearer line of sight tothings like a dedicated memory pool (for slice-of-hardware VMs) andelimination of "struct page" (for offload setups where userspace _never_needs to mmap() guest memory).More immediately, being able to map memory into KVM guests without mappingsaid memory into the host is critical for Confidential VMs (CoCo VMs), theinitial use case for guest_memfd. While AMD's SEV and Intel's TDX preventuntrusted software from reading guest private data by encrypting guestmemory with a key that isn't usable by the untrusted host, projects suchas Protected KVM (pKVM) provide confidentiality and integrity *without*relying on memory encryption. And with SEV-SNP and TDX, accessing guestprivate memory can be fatal to the host, i.e. KVM must be prevent hostuserspace from accessing guest memory irrespective of hardware behavior.Attempt #1 to support CoCo VMs was to add a VMA flag to mark memory asbeing mappable only by KVM (or a similarly enlightened kernel subsystem).That approach was abandoned largely due to it needing to play games withPROT_NONE to prevent userspace from accessing guest memory.Attempt #2 to was to usurp PG_hwpoison to prevent the host from mappingguest private memory into userspace, but that approach failed to meetseveral requirements for software-based CoCo VMs, e.g. pKVM, as the kernelwouldn't easily be able to enforce a 1:1 page:guest association, let alonea 1:1 pfn:gfn mapping. And using PG_hwpoison does not work for memorythat isn't backed by 'struct page', e.g. if devices gain support forexposing encrypted memory regions to guests.Attempt #3 was to extend the memfd() syscall and wrap shmem to providededicated file-based guest memory. That approach made it as far as v10before feedback from Hugh Dickins and Christian Brauner (and others) ledto it demise.Hugh's objection was that piggybacking shmem made no sense for KVM's usecase as KVM didn't actually *want* the features provided by shmem. I.e.KVM was using memfd() and shmem to avoid having to manage memory directly,not because memfd() and shmem were the optimal solution, e.g. things likeread/write/mmap in shmem were dead weight.Christian pointed out flaws with implementing a partial overlay (wrappingonly _some_ of shmem), e.g. poking at inode_operations or super_operationswould show shmem stuff, but address_space_operations and file_operationswould show KVM's overlay. Paraphrashing heavily, Christian suggested KVMstop being lazy and create a proper API.Link: https://lore.kernel.org/all/20201020061859.18385-1-kirill.shutemov@linux.intel.comLink: https://lore.kernel.org/all/20210416154106.23721-1-kirill.shutemov@linux.intel.comLink: https://lore.kernel.org/all/20210824005248.200037-1-seanjc@google.comLink: https://lore.kernel.org/all/20211111141352.26311-1-chao.p.peng@linux.intel.comLink: https://lore.kernel.org/all/20221202061347.1070246-1-chao.p.peng@linux.intel.comLink: https://lore.kernel.org/all/ff5c5b97-acdf-9745-ebe5-c6609dd6322e@google.comLink: https://lore.kernel.org/all/20230418-anfallen-irdisch-6993a61be10b@braunerLink: https://lore.kernel.org/all/ZEM5Zq8oo+xnApW9@google.comLink: https://lore.kernel.org/linux-mm/20230306191944.GA15773@monkeyLink: https://lore.kernel.org/linux-mm/ZII1p8ZHlHaQ3dDl@casper.infradead.orgCc: Fuad Tabba Cc: Vishal Annapurve Cc: Ackerley Tng Cc: Jarkko Sakkinen Cc: Maciej Szmigiero Cc: Vlastimil Babka Cc: David Hildenbrand Cc: Quentin Perret Cc: Michael Roth Cc: Wang Cc: Liam Merwick Cc: Isaku Yamahata Co-developed-by: Kirill A. Shutemov Signed-off-by: Kirill A. Shutemov Co-developed-by: Yu Zhang Signed-off-by: Yu Zhang Co-developed-by: Chao Peng Signed-off-by: Chao Peng Co-developed-by: Ackerley Tng Signed-off-by: Ackerley Tng Co-developed-by: Isaku Yamahata Signed-off-by: Isaku Yamahata Co-developed-by: Paolo Bonzini Signed-off-by: Paolo Bonzini Co-developed-by: Michael Roth Signed-off-by: Michael Roth Signed-off-by: Sean Christopherson Message-Id: <20231027182217.3615211-17-seanjc@google.com>Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Reviewed-by: Xiaoyao Li Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

5a475554 - KVM: Introduce per-page memory attributes

Fri, 27 Oct 2023 18:21:55 +0000

KVM: Introduce per-page memory attributesIn confidential computing usages, whether a page is private or shared isnecessary information for KVM to perform operations like page faulthandling, page zapping etc. There are other potential use cases forper-page memory attributes, e.g. to make memory read-only (or no-exec,or exec-only, etc.) without having to modify memslots.Introduce the KVM_SET_MEMORY_ATTRIBUTES ioctl, advertised byKVM_CAP_MEMORY_ATTRIBUTES, to allow userspace to set the per-page memoryattributes to a guest memory range.Use an xarray to store the per-page attributes internally, with a naive,not fully optimized implementation, i.e. prioritize correctness overperformance for the initial implementation.Use bit 3 for the PRIVATE attribute so that KVM can use bits 0-2 for RWXattributes/protections in the future, e.g. to give userspace fine-grainedcontrol over read, write, and execute protections for guest memory.Provide arch hooks for handling attribute changes before and after commoncode sets the new attributes, e.g. x86 will use the "pre" hook to zap allrelevant mappings, and the "post" hook to track whether or not hugepagescan be used to map the range.To simplify the implementation wrap the entire sequence withkvm_mmu_invalidate_{begin,end}() even though the operation isn't strictlyguaranteed to be an invalidation. For the initial use case, x86 *will*always invalidate memory, and preventing arch code from creating newmappings while the attributes are in flux makes it much easier to reasonabout the correctness of consuming attributes.It's possible that future usages may not require an invalidation, e.g.if KVM ends up supporting RWX protections and userspace grants _more_protections, but again opt for simplicity and punt optimizations toif/when they are needed.Suggested-by: Sean Christopherson Link: https://lore.kernel.org/all/Y2WB48kD0J4VGynX@google.comCc: Fuad Tabba Cc: Xu Yilun Cc: Mickaël Salaün Signed-off-by: Chao Peng Co-developed-by: Sean Christopherson Signed-off-by: Sean Christopherson Message-Id: <20231027182217.3615211-14-seanjc@google.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

f128cf8c - KVM: Convert KVM_ARCH_WANT_MMU_NOTIFIER to CONFIG_KVM_GENERIC_MMU_NOTIFIER

Fri, 27 Oct 2023 18:21:49 +0000

KVM: Convert KVM_ARCH_WANT_MMU_NOTIFIER to CONFIG_KVM_GENERIC_MMU_NOTIFIERConvert KVM_ARCH_WANT_MMU_NOTIFIER into a Kconfig and select it whereappropriate to effectively maintain existing behavior. Using a properKconfig will simplify building more functionality on top of KVM'smmu_notifier infrastructure.Add a forward declaration of kvm_gfn_range to kvm_types.h so thatincluding arch/powerpc/include/asm/kvm_ppc.h's with CONFIG_KVM=n doesn'tgenerate warnings due to kvm_gfn_range being undeclared. PPC defineshooks for PR vs. HV without guarding them via #ifdeffery, e.g. bool (*unmap_gfn_range)(struct kvm *kvm, struct kvm_gfn_range *range); bool (*age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range); bool (*test_age_gfn)(struct kvm *kvm, struct kvm_gfn_range *range); bool (*set_spte_gfn)(struct kvm *kvm, struct kvm_gfn_range *range);Alternatively, PPC could forward declare kvm_gfn_range, but there's nogood reason not to define it in common KVM.Acked-by: Anup Patel Signed-off-by: Sean Christopherson Reviewed-by: Paolo Bonzini Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Message-Id: <20231027182217.3615211-8-seanjc@google.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig

eddd2148 - KVM: Remove CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL

Fri, 11 Aug 2023 04:51:17 +0000

KVM: Remove CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALLkvm_arch_flush_remote_tlbs() or CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALLare two mechanisms to solve the same problem, allowingarchitecture-specific code to provide a non-IPI implementation ofremote TLB flushing.Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardizeall architectures on kvm_arch_flush_remote_tlbs() instead ofmaintaining two mechanisms.Signed-off-by: Raghavendra Rao Ananta Reviewed-by: Shaoqin Huang Reviewed-by: Gavin Shan Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20230811045127.3308641-5-rananta@google.com List of files: /linux-6.15/virt/kvm/Kconfig

441f7bfa - KVM: Opt out of generic hardware enabling on s390 and PPC

Wed, 30 Nov 2022 23:09:33 +0000

KVM: Opt out of generic hardware enabling on s390 and PPCAllow architectures to opt out of the generic hardware enabling logic,and opt out on both s390 and PPC, which don't need to manually enablevirtualization as it's always on (when available).In addition to letting s390 and PPC drop a bit of dead code, this willhopefully also allow ARM to clean up its related code, e.g. ARM has itsown per-CPU flag to track which CPUs have enable hardware due to theneed to keep hardware enabled indefinitely when pKVM is enabled.Signed-off-by: Sean Christopherson Acked-by: Anup Patel Message-Id: <20221130230934.1014142-50-seanjc@google.com>Signed-off-by: Paolo Bonzini List of files: /linux-6.15/virt/kvm/Kconfig