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

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

On Sun, 2017-07-23 at 15:02 +0200, Paolo Bonzini wrote:
> On 18/07/2017 13:51, Mihai Donțu wrote:
> > 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.
> 
> One difference that comes to mind between SKIP and RETRY is that SKIP
> would inject a singlestep exception if TF was 1 on entry, and clear the
> interrupt shadow.  RETRY would not do either of those.
> 
> (The name for SKIP comes from the KVM function
> kvm_skip_emulated_instruction).

OK.

> > We were hoping we can
> > reduce the overhead by a bit by bundling KVMI_SET_REGISTERS with the
> > event response.
> > 
> > If I have not managed to convince you, I think we can go ahead and keep
> > them separate, have an initial implementation and see some actual
> > performance numbers. Should be no hassle. 
> 
> I think you should implement transactions in the protocol, so
> effectively KVMI_SET_REGISTERS would be bundled with the event response
> anyway.

I see. Then maybe we should provide a way for commands to specify an
event ID. If zero, then the command is satisfied using data straight
from the vCPU (when making changes), otherwise a structure associated
with the event will be used as cache for all get-s/set-s and apply them
all in one go when the event reply arrives. This should work nicely
since we read a good deal of the register set anyway when sending the
event.

> > > > 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