2018-12-04 10:19-0800, Jim Mattson: > On Mon, Dec 3, 2018 at 1:53 PM Sean Christopherson > <sean.j.christopherson@xxxxxxxxx> wrote: > > > > The ultimate goal of this series is to break vmx.c's monopoly on all > > things VMX so that it's size goes from utterly ludicrous to merely > > ridiculous. For the most part the patches are simply moving code > > around. There are a few actual code changes sprinkled in, primarily > > to allow moving the nested code out of vmx.c without having to expose > > variables unnecessarily. > > Would this be a good time to think about breaking kvm's monopoly on > all things vmx? That is, move the hardware VMX state management into > an independent layer, so that other hypervisors could also make use of > it? I'm thinking of things like global VPID allocation, tracking of > which VMCS is current on each logical processor (and which VMCSs are > active on each logical processor), etc. The KVM code is quite ready to be abstracted and the resulting overhead should be very low, so my only concern is that it would bit rot without a second user, just like vmm_exclusive did. Now that we're finally splitting vmx.c, I think we could start by separating the code that could be in a separate layer into a separate file(s) in x86/kvm/vmx. This code should be pretty easy to promote later (after ample bikeshedding) and we won't be exporting a potentially broken interface until there is a user for it.
