Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API header for VM introspection

["Mihai Donțu" <mdontu@bitdefender.com>]

On Thu, 2017-07-13 at 09:32 +0200, Paolo Bonzini wrote:
> On 13/07/2017 07:57, Mihai Donțu wrote:
> > > Actually it makes more sense for SKIP, I think, where the introspector
> > > is actually doing emulation?
> > 
> > I'm afraid I don't undestand your question, however we were looking at
> > using KVM's x86 emulator rather than putting together our own, as such
> > software might be fun to write but they take a very long time to get
> > right. I'd argue that KVM's emulator has already seen a lot of
> > coverage.
> 
> Of course!  But there could be some special cases (e.g. hypercalls)
> where you do emulation on your own.  In that case, KVMI_SET_REGS + SKIP
> is the right thing to do.

I think I finally understand what you're saying. That SKIP would tell
the introspection subsystem to just write back the registers and enter
the guest, no in-host emulation needed. So, to reiterate, the possible
actions would be:

 * SKIP - re-enter the guest (the introspection tool has adjusted all
   registers)
 * RETRY - re-enter the guest
 * ALLOW - use the emulator
 * CRASH - kill the guest process

It seems that SKIP requires a variant of KVMI_SET_REGS (_FULL?) that
sets all registers that might have been affected by the emulation
(control, MSR-s, MMX/SSE/AVX). I guess there can be an usecase for
that. It also looks like its identical with KVMI_SET_REGS_FULL + RETRY.

> > In the future we are looking at maybe moving away from it on Intel-s,
> > by way of VMFUNC and #VE.
> > 
> > > But why is KVMI_SET_REGS slower than a set regs command followed by an
> > > action?
> > 
> > To be honest, we just looked at the Xen implementation which gates
> > writing back the registers to VMCS on them actually having been
> > changed.
> 
> That would be possible on KVMI too.  Just don't do the KVMI_SET_REGS
> unless the registers have changed.

-- 
Mihai Donțu