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!
