Message ID | 20191022015925.31916-1-sean.j.christopherson@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: Refactor vCPU creation | expand |
Hi Sean, On Mon, Oct 21, 2019 at 06:58:40PM -0700, Sean Christopherson wrote: > *************************** DISCLAIMER ********************************** > The non-x86 arch specific patches are completely untested. Although the > changes are conceptually straightforward, I'm not remotely confident that > the patches are bug free, e.g. checkpatch caught several blatant typos > that would break compilation. > ************************************************************************* > > The end goal of this series is to strip down the interface between common > KVM code and arch specific code so that there is precisely one arch hook > for creating a vCPU and one hook for destroying a vCPU. In addition to > cleaning up the code base, simplifying the interface gives architectures > more freedom to organize their vCPU creation code. > > KVM's vCPU creation code is comically messy. kvm_vm_ioctl_create_vcpu() > calls three separate arch hooks: init(), create() and setup(). The init() > call is especially nasty as it's hidden away in a common KVM function, > kvm_init_vcpu(), that for all intents and purposes must be immediately > invoked after the vcpu object is allocated. > > Not to be outdone, vCPU destruction also has three arch hooks: uninit(), > destroy() and free(), the latter of which isn't actually invoked by common > KVM code, but the hook declaration still exists because architectures are > relying on its forward declaration. > > Eliminating the extra arch hooks is relatively straightforward, just > tedious. For the most part, there is no fundamental constraint that > necessitated the proliferation of arch hooks, rather they crept in over > time, usually when x86-centric code was moved out of generic KVM and into > x86 code. > > E.g. kvm_arch_vcpu_setup() was added to allow x86 to do vcpu_load(), which > can only be done after preempt_notifier initialization, but adding setup() > overlooked the fact that the preempt_notifier was only initialized after > kvm_arch_vcpu_create() because preemption support was added when x86's MMU > setup (the vcpu_load() user) was called from common KVM code. > > For all intents and purposes, there is no true functional change in this > series. The order of some allocations will change, and a few memory leaks > are fixed, but the actual functionality of a guest should be unaffected. > > Patches 01-03 are bug fixes in error handling paths that were found by > inspection when refactoring the associated code. > > Patches 04-43 refactor each arch implementation so that the unwanted arch > hooks can be dropped without a functional change, e.g. move code out of > kvm_arch_vcpu_setup() so that all implementations are empty, then drop the > functions and caller. > > Patches 44-45 are minor clean up to eliminate kvm_vcpu_uninit(). > > > The net result is to go from this: > > vcpu = kvm_arch_vcpu_create(kvm, id); > | > |-> kvm_vcpu_init() > | > |-> kvm_arch_vcpu_init() > > if (IS_ERR(vcpu)) { > r = PTR_ERR(vcpu); > goto vcpu_decrement; > } > > preempt_notifier_init(&vcpu->preempt_notifier, &kvm_preempt_ops); > > r = kvm_arch_vcpu_setup(vcpu); > if (r) > goto vcpu_destroy; > > to this: > > r = kvm_arch_vcpu_precreate(kvm, id); > if (r) > goto vcpu_decrement; > > vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL); > if (!vcpu) { > r = -ENOMEM; > goto vcpu_decrement; > } > > page = alloc_page(GFP_KERNEL | __GFP_ZERO); > if (!page) { > r = -ENOMEM; > goto vcpu_free; > } > vcpu->run = page_address(page); > > kvm_vcpu_init(vcpu, kvm, id); > > r = kvm_arch_vcpu_create(vcpu); > if (r) > goto vcpu_free_run_page; > What a fantastically welcome piece of work! Thanks for doing this, many's the time I waded through all those calls to ensure a patch was doing the right thing. Modulo the nit in patch 42, the arm64 changes survive a guest boot + hackbench and build fine. The lack of changing the arm-specific destroy function to a void also causes a series of warnings for a 32-bit arm build, but otherwise builds fine. You can add my: Acked-by: Christoffer Dall <christoffer.dall@arm.com> To the arm/arm64 and generic parts. Thanks, Christoffer