On Wed, Mar 15, 2023 at 08:13:37AM -0700, Sean Christopherson wrote: > > A curious question: > > are arch/x86/include/asm/kvm_*.h all expected to be external accessible? > > Depends on what you mean by "expected". Currently, yes, everything in there is > globally visible. But the vast majority of structs, defines, functions, etc. aren't > intended for external non-KVM consumption, things ended up being globally visible > largely through carelessness and/or a lack of a forcing function. > > E.g. there is absolutely no reason anything outside of KVM should need > arch/x86/include/asm/kvm-x86-ops.h, but it landed in asm/ because, at the time it > was added, nothing would be harmed by making kvm-x86-ops.h "public" and we didn't > scrutinize the patches well enough. > > My primary motivation for this series is to (eventually) get to a state where only > select symbols/defines/etc. are exposed by KVM to the outside world, and everything > else is internal only. The end goal of tightly restricting KVM's global API is to > allow concurrently loading multiple instances of kvm.ko so that userspace can > upgrade/rollback KVM without needed to move VMs off the host, i.e. by performing > intrahost migration between differenate instances of KVM on the same host. To do > that safely, anything that is visible outside of KVM needs to be compatible across > different instances of KVM, e.g. if kvm_vcpu is "public" then a KVM upgrade/rollback > wouldn't be able to touch "struct kvm_vcpu" in any way. We'll definitely want to be > able to modify things like the vCPU structures, thus the push to restrict the API. > > But even if we never realize that end goal, IMO drastically reducing KVM's "public" > API surface is worthy goal in and of itself. Got it. Thanks for explanation!
