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
