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
