On Mon, Mar 02, 2020 at 07:42:31PM +0100, Paolo Bonzini wrote: > On 19/02/20 00:29, Sean Christopherson wrote: > > The primary intent of this series is to dynamically allocate the emulator > > and get KVM to a state where the emulator *could* be disabled at some > > point in the future. Actually allowing userspace to disable the emulator > > was a minor change at that point, so I threw it in. > > > > Dynamically allocating the emulator shrinks the size of x86 vcpus by > > ~2.5k bytes, which is important because 'struct vcpu_vmx' has once again > > fattened up and squeaked past the PAGE_ALLOC_COSTLY_ORDER threshold. > > Moving the emulator to its own allocation gives us some breathing room > > for the near future, and has some other nice side effects. > > > > As for disabling the emulator... in the not-too-distant future, I expect > > there will be use cases that can truly disable KVM's emulator, e.g. for > > security (KVM's and/or the guests). I don't have a strong opinion on > > whether or not KVM should actually allow userspace to disable the emulator > > without a concrete use case (unless there already is a use case?), which > > is why that part is done in its own tiny patch. > > > > Running without an emulator has been "tested" in the sense that the > > selftests that don't require emulation continue to pass, and everything > > else fails with the expected "emulation error". > > I agree with Vitaly that, if we want this, it should be a KVM_ENABLE_CAP > instead. The first 10 patches are very nice cleanups though so I plan > to apply them (with Vitaly's suggested nits for review) after you answer > the question on patch 10. Works for me, thanks!
