On 11/07/2017 18:48, Adalbert Lazar wrote: > On Mon, 10 Jul 2017 19:03:06 +0200, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> I'm not sure what you think of removing KVMI_EVENT_ACTION_SET_REGS and >> more or less standardizing on actions SKIP/RETRY/ALLOW/CRASH. >> >> The main remaining issue seems to be map/unmap. > > Definitely, SKIP/RETRY/ALLOW/CRASH looks better, but SET_REGS helps > performance wise. Maybe we could have it as an optional flag for ALLOW? Actually it makes more sense for SKIP, I think, where the introspector is actually doing emulation? But why is KVMI_SET_REGS slower than a set regs command followed by an action? > Or at least for the hot paths? > > Summarily, on events, besides CRASH (vs SHUTDOWN cmd) and any other > additional flag: > > * CR, MSR - ALLOW with untouched new_value will let the guest continue, > but with "new_value = old_value" is a "deny" > > * xsetbv - ALLOW is implied > > * breakpoint - SKIP means the BP is processed by the introspector, > ALLOW means let the guest handle it > > * hypercall - ALLOW is implied > > * page_fault - ALLOW means emulate, RETRY means let guest re-trigger the PF, > ALLOW with adjusted PC is a "skip" (done by the tool > for the moment). This is more complicated than necessary. I would just make it simple: - SKIP, adjust RIP to point to the next instruction and enter the guest - RETRY, enter the guest - ALLOW, emulate the instruction with information coming from the response packet - CRASH, self-explanatory Paolo
